Forem: James Luterek

44 React Interview Questions you should NEVER ask!

James Luterek — Wed, 18 Oct 2023 17:22:46 +0000

Introduction

This blog post is a reaction to the recently published piece on 44 React Frontend Interview Questions. That piece received a lot of attention and to be fair is an excellent guide for those interviewing and trying to land a new position. Learning the answers to these questions and fully understanding them will help you become a better React developer and prepare you for a technical interview on the topic. If you are looking for a job this is a valuable study guide.

However, if you are on the hiring side, these questions fall short. These trivia-style questions will not provide insight into which candidates will make great employees. Anyone in the business knows that this style of information is easily accessed on google and is sometimes not worth committing to memory. We can easily find a list of lifecycle methods and I would argue that not memorizing that list makes us more adaptable as programmers. We should understand why these methods are important, and when to use them, skills that can transfer from React to almost any web development framework.

Instead of asking: “What are the lifecycle methods of a component?” we should be asking: “Tell me about the last time you leveraged a lifecycle method in your component, what problem did it solve, and why did you leverage that technique?”

Here are my tips for those on the hiring side of the table:

1. Focus on Past Experiences

Start with their past. A candidate's history often reveals patterns, accomplishments, and insights into their skill set. If this is a junior position, schoolwork, open-source, and personal projects should absolutely be considered. For entry-level positions broader questions can also provide more flexibility to those with less experience to discuss.

Example Questions:

"Can you describe a challenging React project you've worked on? What made it challenging and how did you overcome those challenges?"
"Describe a time when you had to optimize a React application for performance. What strategies did you employ?"

These questions can lead to a more technical discussion with follow-ups and prompting. Ask about the specific language features used, libraries leveraged, and techniques considered.

2. Understand Their Thought Process

Instead of just looking for the right answer, focus on how they think and approach problems. This is especially true for coding interviews where problem-solving skills are paramount.

Example Questions:

"Walk me through the process you'd follow to create a new feature in a React app from scratch."
"Here's a coding problem. Instead of jumping straight into the solution, can you outline your thought process first?"

3. Determine Their Potential to Adapt

The tech landscape is constantly changing. Today's best practices might become outdated tomorrow. Hence, you need candidates who can swiftly adapt.

Example Questions:

"How do you keep up with the latest developments in React and the JavaScript ecosystem?"
"Can you describe a time when you had to quickly learn a new technology or tool for a project? How did you go about it?"

4. Avoid Trivia

While it might be tempting to test a candidate's memory on specifics, avoid questions that are too focused on trivial details. These often don't reflect a candidate's ability to code efficiently or think critically.

Instead of:

"What is the exact lifecycle method order in React Class components?"

Ask:

"How would you handle side effects in a React application? Can you discuss different lifecycle methods or hooks that could be used?"

5. Craft Real-world Scenarios

Instead of theoretical questions, use real-world scenarios. They give insight into how a developer might perform on the job.

Example Questions:

"Imagine you're tasked with integrating a third-party API into our React app. What steps would you take from start to finish?"
"Describe how you'd structure a large-scale React application to ensure maintainability and scalability."

6. Ask for Feedback

Turn the tables and allow the candidate to ask questions or provide feedback on a hypothetical (or real) piece of code or system design. This not only showcases their analytical and critique skills but also their ability to communicate complex ideas effectively.

Reading and understanding code is important for jumping into an existing project. Reading code will become even more valuable with growing AI tools where a programmer must understand, validate, and improve the code that was initially generated. Or at the very least it ensures a programmer understands the code being copied and pasted from StackOverflow.

7. Test for Self Learning

The tech industry evolves rapidly. It's crucial to gauge a candidate's passion for continuous learning.

Example Questions:

"What's the last technical book you read or course you took? What did you learn?"
"How do you handle situations where you're unfamiliar with a technology or concept?"

Conclusion

So while these React questions make for a good study guide, I believe those of us on the hiring side can do better. Being able to break out of basic knowledge and truly assess technical proficiency, problem-solving skills, adaptability, and potential for growth. Additionally, while the primary goal is to judge the candidate's abilities, the interview process gives them a glimpse into your company's culture and values. The questions you ask and the way you conduct the interview can influence their desire to be a part of your organization. So, strive for an environment that's challenging yet respectful, giving candidates the best opportunity to showcase their strengths.

Subscribe - https://www.youtube.com/JamesLuterek

MPA != Website

James Luterek — Wed, 30 Aug 2023 14:27:48 +0000

I need to rant for a moment about something I see happening repeatedly in the web development space. If you are here for professional educational content go find another article, otherwise buckle up because I’m about to go on an unhinged diatribe of terminology.

We need to unravel a mix-up that's been causing some serious head-scratching. I know this is ground-breaking so brace yourselves: an APPLICATION should never be confused with a WEBSITE. And since you read the title, you guessed it right, if an application is not a website, then a Multi-Page Application (MPA) is NOT, I repeat, NOT the same as a website. Can we please stop labeling websites, the things we’ve been building for decades as an MPA.

Applications are software that handles complex tasks. Originally, they were installed on a computer or server. Think spreadsheets, photo-editing, web browsers and more. By contrast, websites were a way to share information on the internet, consisting of multiple HTML pages accessed via URL. After the introduction of JavaScript, the idea came to build an application with JavaScript. Since this wasn’t a website, it lived on a single HTML page that simply loaded the application code. Hence Single Page Application.

So, WTF is an MPA then? The acronym originally referred to multiple Single Page Applications (SPAs) combined into a single final solution. Hence multi-page as there were multiple. This later became known as micro-frontends, probably because nobody used the term MPA correctly and all just used it to mean website.

I understand, this is how language evolves. A word is created, then the definition of that word is based not on the original purpose, but on how people use it. This is why definitions change over time and words that were once incorrect get added to the dictionary. So, at this point the ship has sailed, an MPA now means website, and website means anything served via a URL.

The problem is… now we need something to distinguish between a content driven website and a functionality rich application. They are completely different concepts that have different needs and considerations. Yes, transitional apps help merge the two allowing frameworks like svelte-kit to bounce back and forth between a server-rendered content page and a functional application, but being able to quickly make and identify the distinction helps clarify what needs to be build, and how we should build it.

Applications, at least what used to be called applications, require a rich UI with lots of interactivity. They need significant code to handle all the functionality. Initial load-time is less of a concern as people will spend hours to days interacting with the application. SEO is not a concern as people enter the application and then work on their own data.

By contrast, websites, or at least what we used to think of as websites, need to share mass amounts of information. They need good SEO considerations so the information can be indexed and quickly found by search engines. Page-load is extremely important as users may only visit one page and leave, and any page of information could be the entry point.

So, now that we as a collective community have completely messed things up by labeling MPAs as websites and completely obliterating the distinction between a website and application, how do we fix things?

I’m all for progress, but this just created confusion and added no value as we simply replaced one term with another less accurate acronym. As I said though, this ship has sailed, the genie is out of the bottle, the train has left the station, we can’t unring this bell. So, I ask the community, moving forward, how do we distinguish between the needs and functionality of Google Sheets and Wikipedia?

Subscribe - https://www.youtube.com/JamesLuterek

Improving paging performance with large data exports.

James Luterek — Thu, 24 Aug 2023 15:27:50 +0000

My work with Elastic Path involves helping companies make amazing ecommerce experiences, but many of these companies are huge enterprises with massive amounts of data. The challenge of handling huge record sets is common and not specific to the ecommerce world. For ecommerce it is often a large customer base or ever increasing list of historical orders, but other fields deal with the same problem of data just in different way. While databases today have become much better at handling this level of data requirements, the need to export or synchronize these records with other systems can still create problems. Elastic Path is API-first, so it’s easy to say, just build an API, but sending all order data in a single request is impossible. Paging is required to make things work, but not all paging is created equally.

The initial approach to building pagination is typically to leverage the systems already built into the database of choice. For MongoDB that means using offset paging with skip() and limit().

This allows each query to skip a predetermined number of records to reach a particular page and then limit the results to that specific page size.

Here is an example of retrieving page 3, with a page size of 10 records:

mongodb // MongoDB query example for offset-based paging db.records.find().skip(20).limit(10);

MongoDB has a default limit of 10,000 records when using skip. This is not an intrinsic limitation of MongoDB, but is a practical limit to ensure good performance and to ensure memory and processing power is not monopolized by paging. Having this limit ensures that paging does not negatively affect the systems overall performance.

When you use offset-based pagination, MongoDB needs to skip a certain number of records to retrieve the desired page of results. However, as the offset value increases, the database needs to perform more work to skip over the specified number of records. This can lead to slower query performance and potential resource exhaustion, especially with large offset values.

Queries become progressively slower as the offset increases, leading to performance degradation.

This is not limited to MongoDB or document databases, PostgreSQL, MySQL, and other databases will also see performance degradation with very large values passed to LIMIT.

While this approach works well for small numbers of records or in cases where you will only show the first few pages of results it proves inefficient for large databases and data exports.

Solution: Cursor-Based Pagination

Cursor-based paging takes a different approach to splitting a dataset into pieces. This takes a bit more setup but can offer better performance when at higher values. Cursor-based paging leverages a unique identifier, the cursor, to navigate through the dataset. Unlike offset paging, where the skip value can lead to deteriorating performance over time, cursor-based pagination relies on a cursor that points directly to a specific record. This ensures consistent and predictable performance.

Cursor-Based Pagination Steps:

Identify your cursor, choose a field that is unique and sortable.
For the first page of results, simply sort by this cursor and limit the number of records.
Grab the last item from this page and make note of the cursor value.
For the next page, include a filter that records must have a cursor greater (or less depending on sort) than the value from step 3.

This approach leverages the database indexes to improve performance so it’s important that the database is configured in a way to optimize the query pattern.

Index the Cursor Field: The field used for the cursor, often an increasing or unique identifier, should be indexed. This helps in efficient retrieval of records based on the cursor value.
Avoid Complex Queries: Keep cursor-based queries simple. Complex queries can hinder the database's ability to optimize and use indexes effectively.
Use Compound Indexes: If your cursor is based on multiple fields, consider using compound indexes, while not ideal it’s better than no index at all.
Regularly Monitor Index Usage: Keep an eye on the indexes' usage and performance. Unused or redundant indexes can impact overall database performance.
Balance Read and Write Operations: Be mindful of the trade-off between read and write performance when adding indexes. Over-indexing can slow down write operations.

Here is an example MongoDB query using this pattern:

mongodb // MongoDB query example for cursor-based pagination db.records.find({ _id: { $gt: lastProcessedId } }).limit(10);

Benefits

The advantages of cursor-based pagination over traditional offset methods are multifaceted. By ensuring consistent and predictable performance, this approach proves highly effective in managing large datasets. It circumvents challenges related to data gaps and duplicate entries that can plague offset paging. Moreover, cursor-based pagination's elimination of record skipping streamlines the processing of new data, enhancing both efficiency and reliability.

If you want to see how this can be put in practice with an API-First solution you can see the Elastic Path documentation.

Learn the foundations of

Composable Architecture

Free Course

Composable vs Monolith

James Luterek — Tue, 18 Jul 2023 17:02:58 +0000

Introduction

In software development, developers traditionally had two options: build a new system from scratch or buy a monolithic software and hope it meets the requirements. A new paradigm labeled as composable, driven by APIs and the need for new UX touchpoints, has emerged to provide a new option.

Understanding the Terms

What is Composable Commerce?

Composable Commerce and Composable Architecture is creating a new solution by combining (or composing) multiple API-first software into a cohesive and powerful final experience. The final design involves multiple APIs covering the different business requirements, data orchestration, Backend-for-Frontend, and multiple frontends including a robust website. A good example is leveraging an authentication provider or email sending service instead of building one from scratch.

What is Headless Commerce?

Headless Commerce is similar in that you have an API layer and multiple frontends. The major difference is that in a headless solution all of the APIs may come from a single source. This brings it much closer to a monolithic software system where everything is built together, except instead of creating a theme which is rendered via the server, a SPA/PWA is deployed which calls the APIs. This provides more flexibility in theming and design, but lacks the same level of customization and selection you get with a composable system.

What is a Monolith or Monolith Commerce System?

Monolithic Commerce Systems provide a single software solution where everything is built together often in a single project and code base.

The spectrum of commerce systems ranges from a monolith - one massive piece of software, to composable - breaking the system up into more manageable, customizable chunks.

Major Differences

Customization

Composable solutions offer easier customization, allowing businesses to mix and match components and retain full control over the User Experience (UX). Monoliths, conversely, are difficult to customize. While composable solutions rely on multiple API-first software components, these components are small enough to be generic - there is no need to “reinvent the wheel.” Unique features, on the other hand, can still be built out with custom code.

Maintenance

If you build the composable system with SaaS APIs, such as Twilio for messaging or Amazon S3 for storage, maintenance costs are lower, and updates are easier. The underlying systems can be patched and improved without impacting the overall software. Monoliths, on the other hand, require everything to be patched, updated, and maintained together, which means higher maintenance costs. This also raises the risk of downtime.

Level of Effort

Composable Commerce systems requires a similar level of effort to deploy, regardless of business complexity. The bulk of the work is in setting up the initial design and infrastructure, but changes, improvements, or adding functionality over time are considerably easier. Monoliths start extremely easily, enabling a basic setup in a matter of hours or weeks. However, as business requirements increase in complexity, the level of effort rises exponentially.

This makes composable the obvious choice for complex, unique, or large software projects, but also for any projects that will grow over time.

Key Benefits and Drawbacks of Each

Monolith Commerce Systems

Monolith Commerce Systems present certain advantages such as out-of-the-box functionality. The decisions and architecture are predefined by the vendor, saving businesses the task of deciding on each aspect of the system. However, these benefits come with certain disadvantages. There's the risk of vendor lock-in, meaning that businesses are tied to their vendor's system and can't easily switch to another provider. This setup can also lead to slower adaptation to market changes. Businesses might find themselves struggling to update their commerce systems as quickly as they would like due to these constraints.

Composable Commerce

On the other hand, Composable Commerce brings flexibility, agility, and scalability to the table. Businesses can adapt more swiftly to market changes, enabling a faster time to market for their products or services. Additionally, they have the freedom to leverage any coding language or tools, as composable commerce systems make use of standard APIs. However, these benefits require careful management. Businesses might find themselves handling multiple vendor contracts, and it's essential to have a clear understanding of their requirements right from the beginning. These potential challenges need to be weighed against the benefits of a composable commerce system.

Potential Use Cases

Monolith Commerce Systems

Suitable for small businesses, website-centric businesses, industries with stable and standard requirements, and companies with basic processes and less competition.

Composable Commerce

Ideal for large businesses, businesses with unique requirements, companies that need a multi-touchpoint solution (website, mobile, etc.), companies aiming for modern technology, complex business models like B2B2C, and businesses that require a high level of differentiation through unique branding and experiences.

Blend

Composable is not all-or-nothing. You can borrow aspects of composable architecture into a larger monolithic system, start the process of going composable with headless solutions, or integrate composable services in your custom-built software.

Conclusion

Every software decision involves trade-offs - there is no one-size fits all answer. The choice between a monolith and composable commerce system depends on the business needs, scale, and the level of customization required. Composable Commerce offers significant advantages in terms of flexibility, customization, and scalability, but has a higher upfront level of effort.

Subscribe - https://www.youtube.com/JamesLuterek

Building Blocks of Composable Commerce

James Luterek — Tue, 18 Jul 2023 17:02:52 +0000

Composable Commerce breaks down into three main requirements, front-end, APIs, and integrations. The front-end will consist of any UI or customer touchpoint, the most common being a website, but could also include mobile applications, POS systems, AR/VR, and more.

The integrations help to combine the multiple APIs, but also to move data between them.

Finally, they APIs themselves. These are typically SaaS services and are typically what is meant when people talk about the building blocks of composable. These could include:

Product Information Management (PIM)

Products live at the center of digital commerce, without a product there is nothing to sell. A robust PIM is a foundational component and an excellent starting point. PIM enables businesses to store, manage, and maintain consistent product data. This includes attributes, descriptions, images, and technical specifications. By centralizing this core product information, a PIM helps ensure accuracy across touchpoints rather than duplicating data manually across multiple systems.

Traditional PIMs focus on the creation of products and may not be designed for serving that data to websites or mobile applications. In some projects it may be beneficial to keep the traditional PIM and add a digital PIM for enriching the data and propagating that data through scalable APIs.

It’s important for the PIM to be flexible, allowing for many prices, catalogs, languages, and variations. Limitations in the PIM will cascade down through the rest of the implementation.

Product Discovery / Search

Once the product data is defined, the next step is to enable customers to quickly find the products they need. This starts with a robust search engine which should go beyond a basic keyword search and include advanced filtering, personalized recommendations, boost/bury functionality, and configurable facets. Depending on the products, the search may also need to handle large catalogs with many variations.

The product search service also needs to be API-First and scalable, it will be responsible for powering product listing pages (PLP) and product search pages, which are both at the top of a traditional commerce funnel and get a significant amount of traffic.

Order Management System (OMS)

The OMS takes control after an order is placed. While the customer rarely interacts with the OMS, it is responsible for processing, tracking, and managing all the orders. The OMS can also participate in inventory management, payment processing, shipping, and returns. Having an extensible OMS is important to define all of the data that needs to be tracked as well as supporting custom life cycles or workflows. Having an OMS that can be properly integrated with APIs helps ensure an efficient and transparent fulfillment process, which creates higher customer satisfaction and lower support volumes.

Customer Relationship Management (CRM)

CRM tools create a unified view of each customer, storing interactions, preferences, purchase history, and enable more targeted marketing and personalized experiences. Many CRM tools also provide identity management allowing for streamlined authentication through social login. It is possible to split the customer profile and authentication into multiple services depending on the overall requirements. Since the CRM aggregates all of the customer data from other systems, choosing a solution with strong APIs is a must.

Content Management System (CMS)

It is possible to make a basic ecommerce system without a CMS, but the majority of companies have heavy content requirements and need to empower business users to make content changes. As a result almost all composable commerce implementations include a headless CMS. The CMS facilitates the creation, management, and publishing of digital content across all customer touchpoints. A major difference between traditional CMS solutions and headless CMS options is how they treat this data. The traditional system took a webpage view of content, often mixing content and markup, resulting in data that would need to be modified or adjusted when used in a mobile application or other channel. A headless CMS removes any artifacts related to the channel, so rather than creating a page with markup, a schema is defined to store the clean content which can then be formatted as necessary.

There can often be confusion between a headless CMS and a PIM. While it is possible to build a schema and represent products in a CMS, this brings issues and limitations to the project. It will also require rebuilding all business logic that the PIM provides. Instead, core product data should always be stored in the PIM. There are some circumstances where product content is split between a PIM and CMS, in these situations base product data lives in the PIM while extended details may be best suited for a more visual editor found in a CMS. It’s important to talk with an experienced architect to help decide where data should be allocated.

Payment and Fraud Detection

Payment gateways are a clear requirement for any digital commerce experience, not just composable solutions. By choosing composable API-first options for all components, more data can be leveraged when handling fraud detection. Especially data from the OMS and CRM to identify repeat offenders or unexpected behavior.

Summary

While this covers the core systems required in basically all composable commerce systems, the final solution is designed around a business’ specific needs and could include other specialized systems. These may include marketing automation, tax management, translation service, data warehouses, among others. These systems can be added or removed as requirements and objectives change. As a result, the need for extensive RFPs covering each possible requirement, current or future, is no longer necessary. Instead, the solution can evolve and grow over time, so functionality missed on initial launch can be quickly incorporated.

Subscribe - https://www.youtube.com/JamesLuterek

Principles of Composable Architecture

James Luterek — Tue, 18 Jul 2023 17:02:42 +0000

As a high-level definition we discuss composable in combining multiple building blocks, each solving for a business requirement. Digging deeper on the technical implementation, it’s clear that these building blocks must follow specific rules to ensure they can be leveraged and combined effectively. Combining many small monoliths would be a huge task, but services that apply these principles become easy to work with, extend, and merge making them fit the definition of composable.

API-First

API (Application Programming Interface) is a set of rules and access patterns that allow different software applications to communicate. While it is possible for API to be added to a monolithic system, taking an API-First approach prioritizes the design and flexibility of these APIs. An API-First design guarantees that all functionality is exposed via API and that the API contract is well thought-out rather than being a consequence of how the data is stored or the expected UI. An API-First service can be used to build any type of user experience, where APIs added later are highly influenced by the existing user interface and adds restraints to how it can be leveraged. Taking a flexible API-First approach is necessary for seamless integration between the many services leveraged in a composable architecture.

The term “Headless” is related to APIs. Headless defines a system where the frontend (client-side) and backend (server-side) systems are decoupled, allowing for independent development and deployment of each. This separation allows for a higher degree of UI customization than standard theming solutions.

Be careful when selecting services, while all API-First services can be considered headless, not all headless software is API-First. Some headless offerings were tacked on to existing monolithic applications and do not give the same level of freedom when accessing the API.

Modular Components and Services

This principle requires that all the building blocks are discrete, interchangeable modules, each responsible for a specific functionality. Each building block should be consumable individually without reliance or dependencies on other services. A lack of tight coupling ensures the service can be used where necessary and replaced if another service better fits the requirements.

This may sound very similar to microservices. Microservices are a cloud architecture design where an application is deployed as a collection of small, focused containers, often within a Kubernetes environment.

The major difference is that microservices can be loosely coupled and are typically deployed together in the same environment to minimize latency for intra-service communication. Composable services must be fully decoupled, are often provided by different vendors as a SaaS, and focus on a business need or requirement.
While microservices are not required to be a composable service, choosing solutions built on microservices guarantee a high level of modularity and typically have a greater ability to scale.

Cloud Native

While any application can be hosted in the cloud, cloud-native applications fully exploit the unique services cloud computing provides, both in how they are hosted and with configurable integrations connecting to those services.

While a traditional cloud-hosted monolith may require a virtual server for each instance, a cloud-native SaaS will leverage scalable containerization designed with auto-scaling to serve all users. This creates scalability and cost-efficiency. This is extremely important for composable commerce, as a virtual server has limits on scale, must be managed directly, and represents a point of failure for days of increased volume (e.g. Black Friday). This level of maintenance would be cost-prohibitive when combining many different solutions. Instead composable solutions must be resilient and reliable guaranteeing they will handle any traffic without manual configuration or maintenance.

Composable solutions also take an event-driven approach to data movement and allow end-users to subscribe to these events. These events could be exposed via webhooks, but the best providers can also tie directly into cloud services and publish the events to a queue. Having access to the events allows for real-time integrations and negates the need for scheduled jobs or large batch files.

Subscribe - https://www.youtube.com/JamesLuterek

Introduction to Composable Commerce

James Luterek — Tue, 18 Jul 2023 17:02:33 +0000

Defining Composable Commerce

Composable Commerce is a new approach to building out unique digital commerce experiences. Historically, businesses were forced into two distinct approaches: buying generic software that can be themed and lightly customized, or coding an entire solution from scratch. Composable Commerce provides a third approach. By breaking traditional software functionality into smaller pieces, each offered separately, they can then be used as building blocks to create custom software without extensive coding.

Benefits vs challenges of composable commerce

This approach allows every business the benefit of a custom solution, while matching the cost and effort associated with buying generic software. For businesses with unique requirements, who want to control the entire customer experience, or who hope to leverage cutting-edge techniques, composable commerce is an easier and cheaper solution than forcing these requirements into an existing software package. This enables businesses to quickly adapt to changing requirements, customer preferences, and marketing conditions, and to quickly take advantage of technological advancements.

Due to the architecture principles required to create these building blocks, the individual services benefit from better scalability, lower maintenance, and faster response times. Since each individual piece can be swapped out as requirements shift, there is no need for massive re-platforming projects, instead the system grows and evolves over time.

The major challenges of composable commerce are the initial investment in planning and designing the solution. When buying all-in-one software, the vendor defines what functionality will be delivered. With composable commerce more time is spent on defining the overall requirements to ensure the best pieces are identified and integrated. Additionally, with this being a new approach businesses and architects may face a steeper learning curve as they adapt. Thankfully, there are now experts with years of experience ready to assist in navigating the many possible components and services.

Composable commerce vs composable architecture

Composable commerce refers to the use and application of composable architecture for digital commerce solutions. Composable architecture is broader, defining the use of these concepts across any industry or project. Composable commerce is a subset of composable architecture, but highly focused on meeting the unique needs of selling online.

Subscribe - https://www.youtube.com/JamesLuterek

Syncing Inventory: Incrementing vs. Overwriting

James Luterek — Wed, 05 Jul 2023 13:29:57 +0000

Tracking inventory in the world of digital commerce is crucial for both customers who expect their items delivered and business who need to ensure items do not sit in the warehouse unavailable for purchase. While tracking a simple count appears to be a basic programming task, the reality involves multiple systems from an e-commerce system to an ERP (Enterprise Resource Planning), each reading and writing values at high volumes, it is essential to employ the right approach to ensure data integrity. This type of high-throughput system requires additional care, the correct programming approach, and back-up solutions like safety stock values to avoid major pitfalls such as race conditions.

Scenario: Let's consider a scenario where an ERP is the source of truth for inventory data, handling receiving and fulfillment. In addition to the ERP there are multiple customer touch-points including traditional ecommerce, a mobile application, and in-store functionality which can sell the items in inventory. The ERP can be slow and handles many functions, so to remove the burden of constant inventory checks, the inventory levels are synced to an API-based online inventory system that can serve the customer touchpoints. When an order is placed, the online inventory is decreased and the order is sent to the ERP, processing the order in the ERP decrements the master inventory level. In this dynamic environment, simultaneous updates to inventory quantities can occur, and it becomes crucial to handle these updates in a manner that maintains data accuracy and prevents conflicts.

The first approach may be to simply copy the inventory values from the ERP into the online inventory system. In order to keep things up to date, the values may be copied in a CRON job running every 5 minutes. On first launch this appears to work well and in low-volume systems may continue to perform as required. However, as volumes increase values will quickly become inaccurate leaving gremlins in the code, bugs that are highly situational and almost impossible to reproduce. The problem is that syncing data is never instantaneous and with so many events firing it becomes likely for changes to take place after the inventory value is retrieved, but before it is fully synchronized.

Incrementing or Decrementing Values for Syncing: Instead of overwriting the inventory count with a new number during syncing, a more reliable approach involves incrementing or decrementing the existing value. This method ensures that each inventory update considers the changes made by other processes, reducing the risk of data inconsistencies and race conditions. So, a well-designed inventory API will accept an increment or decrement integer which will be applied to the existing quantity rather than taking the quantity as a direct value. You can see an example API on the Elastic Path docs website.

Incrementing or decrementing values offers several advantages:

Data Integrity: By incrementing or decrementing values, existing data remains intact, reducing the risk of data loss or discrepancies during inventory updates.
Concurrent Updates: In a dynamic e-commerce environment, multiple systems or users may simultaneously update inventory counts. Incrementing or decrementing values allows for sequential application of updates, preventing conflicts and maintaining the accuracy of stock levels.
Audit Trail: Incrementing or decrementing values provides an audit trail of inventory changes. Each transaction or adjustment made to the inventory count can be tracked, enabling better accountability, error analysis, and identification of discrepancies.
Granularity: Incrementing or decrementing values allows for granular tracking of individual item changes. This detailed record of added or removed items facilitates better traceability and analysis of inventory fluctuations.
Historical Reporting: Incrementing or decrementing values preserves historical data, enabling the generation of accurate reports based on past inventory levels. This information is invaluable for analyzing trends, forecasting demand, and making informed business decisions.

Even taking this approach there is still the potential for syncing delays. Inventory may leave the warehouse, but also be sold before the sync is completed, causing an over-sold situation. To combat this issue, it may be beneficial to access the master inventory record during checkout to verify the inventory levels. However, since this process is slow it should only be done when absolutely necessary, this is the role of Safety Stock Values.

We can track a minimum safe quantity in our online system, if the quantity shown is below this value during checkout the system should verify with the ERP. The easy way to handle this requirement is to set a single value for the entire system. A more robust approach is to store the safety stock value within each inventory entry and calculate the necessary value based on recent sell-through of the specific SKU. This is possible with an API system that allows for custom fields, but can be more difficult with a more rigid ecommerce platform.

While this example is tied directly to ecommerce, the approach can be applied to any distributed system where multiple processes need to read, update, and cache a single value. Choosing an increment/decrement approach allows for better syncing by tracking changes instead of point-in-time values and additional business logic can be created to mitigate issues from syncing delays.

Learn the foundations of

Composable Architecture

Free Course

Creating "Buy-Again" Purchase Flows

James Luterek — Wed, 28 Jun 2023 16:03:18 +0000

Learn the foundations of

Composable Commerce Architecture

Free Course

In this tutorial, we will walk you through the process of enabling "Buy-Again" purchase flows streamlining the ordering process for customers who have large high-value carts and make standard, repeat orders. The purpose of this functionality is to streamline the purchasing process for your customers, increasing the likelihood of repeat business and building customer loyalty.

By leveraging the power of Elastic Path Commerce Cloud, an API-first commerce solution, adding this type functionality is straight forward and easy to create. The flexibility of APIs allows companies to build unique features that feel seamless to end-users. Enabling custom features like "Buy-Again" can be added without disrupting the user interface, requiring extensive plugin coding, or destabilizing and slowing down the overall system by adding custom code to the core. Instead the functionality can be added directly to the front-end without the use of iframes or other hacks, and the logic can be executed with a small amount of JavaScript calling the APIs.

Step 1: Place an Order

Before a customer can buy again, they must create and place a new order. The customer creates their first cart and completes the checkout process, this order and all details are then stored in their order history and accessible via API. This information can then be retrieved later when the customer needs to "Buy-Again”.

Step 2: Identify order to Repeat

The next step is for the customer to select the order they want to repeat, this step is traditionally taken from the order history section in an account profile, but the freedom of an API-First approach means it can happen from any location, even a link from the past order confirmation email or a reminder text. The import aspect is that the customer has an easy wait to find and identify the order they want to repeat.

sequenceDiagram
  Customer->>Profile: View Profile
  Profile->>Order History: Retrieve Order History
  Customer->>Order History: Selects Order to Repeat

Step 3: Order->Cart

Create a Function to Query the Selected Order
While the normal process is for a cart to be converted to an order, the similar schema mean the opposite is also possible and easy to accomplish. At this point, code will be called that retrieves the order and leverages the details to populate either a new or existing cart. Since pricing and inventory may have changed, rather than copy all details, instead we can simply extract the line-items from the order and add them to the user’s existing shopping cart, if no cart exists, create a new one.
Here's some example code:

const MoltinGateway = require('@moltin/sdk').gateway;

const Moltin = MoltinGateway({
  client_id: 'YOUR_CLIENT_ID',
  client_secret: 'YOUR_CLIENT_SECRET',
});

async
function repeatOrder(orderId) {
  // Get the order details
  const orderDetails = await Moltin.Orders.Get(orderId);

  // Extract line items
  const lineItems = orderDetails.data.line_items;

  // Get or create the user's cart
  const cart = await getOrCreateCart();

  // Add line items to the cart
  for (const item of lineItems) {
    await Moltin.Cart(cart.id).AddProduct(item.product_id, item.quantity);
  }
}

Step 4: Customer Reviews the Cart and Makes Changes (Optional)

Once the items from the previous order have been added to the cart, the customer can review their cart and make any necessary changes.

sequenceDiagram
  Customer->>Cart: Review Cart
  Customer->>Cart: Make Changes (Optional)

Step 5: Checkout

Finally, the customer proceeds to the standard checkout flow, completing their "Buy-Again" purchase.

sequenceDiagram
  Customer->>Checkout: Proceed to Checkout
  Checkout->>Order Confirmation: Complete Purchase

Summary

Making it easy for customers to quickly repeat their orders can increase sales and increase customer loyalty by reducing friction and improving the user experience. Unique features like this "Buy-Again" purchase flow can boost a company’s competitive advantage..

As demonstrated, the flexibility of Elastic Path Commerce Cloud’s API-first approach allowed us to implement this feature with only small and seamless front-end modifications. There was no need for complex plugins, extensions, or learning new coding techniques as it was all standard JavaScript.

Here's a diagram of the entire process:

flowchart TB
  A[Customer Makes Original Purchase] --> B[Customer Selects the Order to Repeat]
  B --> C1[[Query the Order JSON]]
  C1 --> C2{Cart Exists?}
  C2 -->|NO| C3[Create Cart]
  C2 -->|YES| C4
  C3 --> C4[[Add Line-Items to Cart]]
  C4 --> D[Customer Reviews the Cart and Makes Changes]
  D --> E[Customer Goes Through the Standard Checkout Flow]

Learn the foundations of

Composable Commerce Architecture

Free Course

kdenlive - Open-Source Video Editing

James Luterek — Wed, 17 May 2023 16:25:39 +0000

I recently started a new podcast. I knew the audio would be published across multiple services, but also wanted a video version for youtube. With a background in programming, this left my trying to figure out how to accomplish this task.

There are many video editing software options available, which was extremely overwhelming, each had different requirements and prices attached. Instead I went to my roots and looked at the open-source offerings. This is what brought me to kdenlive, software that can run on Windows, Mac, and Linux. Kdenlive, stands for KDE Non-Linear Video Editor. As you would expect the software lives under the KDE umbrella of applications. I used the software with both windows and PopOS!, while the linux version felt more stable, both worked well.

Multiple Video and Audio Streams
The recordings made for this podcast involved three mic inputs and two camera inputs (with audio). All of these tracks needed to be managed separately, which Kdenlive is able to do. The video sources were linked with their audio track, but could be separated where necessary. All tracks could be synced automatically by their audio ensuring the different sources lined up properly.

The multiple video sources were great for making a more engaging video, but also allowing for easier cuts. Content could be edited without making a jarring video cut by switching between the different camera sources.

To manage multiple streams, Kdenlive uses a timeline-based interface. Each video or audio stream is placed on a different track, which can be independently edited, enabling you to fine-tune every aspect of your project. It's as simple as importing your media files and dragging them onto the timeline.

A Robust Ecosystem
The leading commercial options have massive ecosystems with templates and guides for sale everywhere. This was a concern going open-source and with a less popular software option. I was pleasantly surprised by the vibrant ecosystem that includes plenty of help content, tutorial videos, user forums, and more. The official Kdenlive website has a comprehensive manual covering all aspects of the software, including beginner-friendly tutorials and more advanced topics.

There is also an active community of Kdenlive users who regularly create and share tutorial videos on various aspects of the software. From basic editing techniques to more advanced effects and transitions, these tutorials provide a wealth of knowledge for any level of user.

Any time I needed to do something new, there was a video tutorial or guide ready to help guide me through the process. This ecosystem and community made the software accessible for a complete video editing beginner.

Free and Open-Source
Kdenlive is a free and open-source project. I’m sure this community understands the massive value of open-source and the benefits it brings.

Beginner Friendly
Despite its powerful capabilities, Kdenlive felt very accessible to beginners. Its interface felt very intuitive and any difficult functionality had a wealth of tutorial videos available. Its design allows users to grow with the software. As you become more comfortable with its basic features, you can gradually start exploring its more advanced capabilities, changing the interface layout, and leveraging more keyboard shortcuts, making Kdenlive a great choice.

Final Thoughts
I will continue to leverage Kdenlive for my future video editing requirements. If you want to see the final outcome the video can be found here.

If you want to get started with kdenlive, checkout their website or github.

Subscribe - https://www.youtube.com/JamesLuterek

5 Production ready APIs for your next project.

James Luterek — Tue, 21 Feb 2023 20:58:22 +0000

As a developer, finding the right API for your project can be a game-changer. A well built API can significantly reduce your project timeline, make your life easier, and result in a more robust result. APIs are the foundation of a composable architecture and reason small development teams can build amazing highly complex applications. However, not all APIs are created equal. Some require a significant investment upfront, some are open-source allowing you to test it locally, while others offer free sign-ups or trials to help you test the waters. In this blog post, we will be discussing production APIs for developers and for each category offer the leading SaaS and open-source alternative.

1. Search

Most applications can benefit from a robust search, but search engines are difficult to build and expensive to maintain. It does not make any sense to build your own search when there are great solutions available.

Algolia

Algolia Free Sign-up

Algolia is a search and discovery API that enables developers to build fast and relevant search experiences for their applications and websites. It provides a powerful and easy-to-use search solution that includes features such as typo-tolerance, faceting, geolocation, and personalization. Algolia's API can be easily integrated with many different platforms and programming languages, allowing developers to quickly implement advanced search functionality without the need for extensive backend development. With Algolia, businesses can improve their user engagement, conversion rates, and revenue by providing a fast and intuitive search experience for their users.

Elastic Search

Elastic Search GitHub

Elasticsearch is an incredible open-source search offering. It offers the APIs necessary to power an amazing search experience. Elasticsearch is freely available for download, modification, and redistribution under the Apache 2.0 license.

2. Content Management System

While it's tempting to embed content directly in the code or leverage basic markdown files, once a project is large enough to have business contributors and CMS is needed. These CMS options offer an API-First approach to ensure they are easy to integrate.

Contentful

Contentful Free Sign-up

Contentful is a modern content management platform that allows developers to create, manage, and publish digital content across various channels and devices. It offers a flexible and API-first approach, enabling developers to easily integrate content into their applications and websites. Contentful is used by businesses of all sizes to streamline their content workflows and improve the delivery of their digital content.

Strapi

Strapi GitHub

Strapi is an open-source API-First CMS option built with NodeJS and designed to be simple, secure, and fast. Strapi is freely available for download, modification, and distribution under the MIT license.

3. Backend as a Service

Backends as a service (BaaS) allow front-end and mobile developers to build entire applications without the need for server-side coding. They can help in building applications fast allowing teams to launch earlier than trying to build the back-end from scratch.

Firebase

Firebase Free Sign-up

Firebase is an app development platform that helped create this space. Built by Google and hosted on Google Cloud it provides most APIs needed to build an app or SPA.

Supabase

Supabase GitHub

Supabase started as an open-source Firebase alternative, but has grown to include it's own unique set of features and functionality. Built on PostgreSQL it offers a great REST API and SDKs in most programming languages. Offered under the Apache License v2.0 you can download, modify and self-host this BaaS on your own server or cloud environment.

4. Ecommerce

Ecommerce feels like a manageable project until you being diving into the weeds of product bundles, promotions, and payments. Ecommerce represents the classic ninety-ninety rule, where the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. This is why it's best to leverage an ecommerce solution instead of building it yourself.

Commerce Layer

Commerce Layer is API-first and extremely focused. While other companies attempt to handle everything, this company has narrowed the focus to checkout, the core of ecommerce. With a free developer tier and clear published pricing, it's a great option for large businesses.

MedusaJS

Medusa GitHub

Medusa is an open-source headless commerce engine built with Node.js. Medusa is known as the open-source Shopify alternative, but while geared towards the same market, takes an API approach ensuring developers have a great experience. Using the MIT License the software is very easy to setup and get started. The robust documentation will help in creating your first Medusa app, making any desired modifications, and hosting the final solution.

Being purpose built for commerce, Medusa contains many of the endpoints and business logic required for setting up an online store.

5. Authentication

While it's tempting to built your own login system, these are rarely secure. In addition people expect advanced features including social login, 2-factor, passwordless and more.

For this reason it's a good idea to leverage an existing solution.

Auth0

Auth0 Free Sign-up

Auth0 makes it extremely easy to integrate authentication into your application. Recently purchased by Okta it is a good choice with many enterprise companies leveraging it's APIs.

SuperTokens

SuperTokens GitHub

SuperTokens is an open source authentication solution offering different types of login, access control, session management, user management and more.

The software is built with Java and offered under an Apache license.

Conclusion

Composable Architecture is all about combining APIs into a great final solution instead of trying to re-invent the wheel for each requirement. There are so many API-First offerings you can find something to fit your needs regardless of how niche. This list has only a few of the enterprise SaaS and self-hosted open-source solutions available.

Subscribe - https://www.youtube.com/JamesLuterek

10 Cringe-worthy Tech Terms

James Luterek — Thu, 02 Feb 2023 16:32:03 +0000

When expressing ourselves online, we must use succinct technical language to optimize synergy between the communicator and reader ensuring all verticals understand the paradigms being expressed guaranteeing understanding to ensure sustainable digital transformation.

Wait!?!? That sentence is ridiculous and full of meaningless jargon!

I understand the desire to sound smart, and buzzwords can add a feeling of technical knowledge to hide behind, where using simple terms makes it easy to identify when the writer doesn't fully understand the topic.

Over-use of buzzwords makes content difficult to understand and ultimately causes technical terms to lose their original meaning. This is how a technical term goes from being an descriptive industry-specific word, to a meaningless marketing phrase.

Good vs Bad Tech Terms

Not all tech terms are jargon or misused as buzzwords. In fact many start as useful tech terms, which are then abused, forcing the tech community to invent a new way to accurately describe that topic.

Good terms are industry-specific, and when used correctly, clearly express an idea, function, or technology. They come up naturally in conversation and people familiar with the term all have the same definition.

Bad terms tend to fall in three categories.

Terms invented by marketing to help sell a product, so they are not grounded in technology.
Business language, where words are replaced to sound smarter, words like leverage, utilize, and synergy.
Abused terms, words that once had a strong meaning, but through overuse they no-longer have a single definition and are just thrown around with no purpose.

Here are 10 top offenders:

Bandwidth
Double Click
JAMStack
Ecosystem
Web3
Headless
Microservices
Sunset
Cloud
Unplatform

1. Bandwidth

Bandwidth was a great term, it represented the rate of data transfer possible. It has been abused to represent anything with constraints, the most popular being how much time a person has.

Sure, it may sound technical to state the team doesn't have enough bandwidth to complete the project, but it's much less clear than just saying time or manpower.

We are not computers. Next I will hear managers talking about meetings requiring too many brain CPU cycles.

2. Double Click

When leveraging a mouse you can left-click, right-click, middle-click, or double click on a screen element. Each performs a specific distinct action depending on the interface. Seems easy enough.

Instead the new meaning for "double click" is to dive deeper on a specific subject. "Let's double click on that" is a fancy way of saying, "we should talk more about that".

This one is extra cringe-worthy, because while it tries to sound technical and smart, instead it feels aged in a world of touch-screens. What's next? "Let's pinch to zoom on that topic."

3. JAMStack

JAMStack is an acronym representing Javascript, APIs, and Markup. JAMStack websites were built with Javascript, leveraged APIs to pull data, and pre-compiled everything to Markup so it could be deployed as a static website on a CDN. This created a very fast and secure website.

Of course, not everyone wants a static, pre-compiled, website. In addition, the new trend for edge computing and Transitional Apps makes JAMStack a less compelling option. Ideally, JAMStack would lose popularity, but remain a relevant niche with a clear meaning. However, the term has buzz with a community, conferences, and more, so instead of allowing the term to lose relevance companies broadened the definition.

Now JAMStack is used for any JavaScript website. SPA, PWA, Transitional App, heck even if you use some JQuery to make an AJAX call people will claim it's JAMStack. The term is becoming so generic it has lost all usefulness, beyond being a buzzword. I guess it sounds better to say the website is JAMStack then stating it uses Javascript, plus it can lean on the reputation of speed and security from it's static roots, without actually providing those benefits.

4. Ecosystem

We all learned about ecosystems in high-school science class. It's a community of organisms and their physical environment.

The term has been hijacked to make software solutions feel large. Before there were certified developers that can help with the project, now there is a full ecosystem. A large amount of plugins or extensions have become a robust ecosystem. It does add more syllables, just look at the "internet of things ecosystem", definitely a mouthful.

5. Web3

At this point, I'm not sure what the original definition of Web3 is. If anyone knows the origins of the term please add a comment.

In it's current use it includes Blockchain, AI, VR, AR, Metaverse, or any technology that has been created in the last few years. Where web1 and web2 were coined after the transition, web3 has been used as a buzzword before it gained traction.

At this point startups use the term web3 just to sound modern and push for more VC funding.

6. Headless

The tech world has had headless computers and headless software for decades. The meaning was clear, a system designed to be used without a UI, headless computers have no keyboard or monitor, headless browsers can only be used from code.

Lately we have headless CMS and headless commerce. While these originated with software that was actually headless, today companies use headless to mean decoupling the backend and frontend, so most offer a UI - often a JAMStack website ;-P

I'm curious how many terms and variations I'll have for API in my lifetime. Thin Client, AJAX, JAMStack, Headless... yes they are slightly different, but pull away the fancy terms and you are left with an API.

7. Microservices

Microservices gained popularity with k8s as a new approach to designing large and complex applications. It has offered great success to companies including Netflix, Amazon, Spotify, and more.

As it gained popularity, it also grew in scope. From a clearly defined architecture it now represents anything broken out into pieces.

Use serverless functions in your application? Microservices
Split your engineers up into multiple teams? Microservices
Company built more than one application? Microservices

It's become a silver-bullet so everyone tries to cram the term in. The biggest abuse I've seen is the term microservices as a synonym for any fast scalable software.

8. Sunset

I'm personally a sunrise person, but there is no denying the beauty of a great sunset... except in the tech world.

Sunset has become the go to phrase for killing off a product, project, or feature. The term is extremely cringe-worthy as everyone knows it's an attempt to soften the blow. It's similar to companies parting ways with employees instead of admitting to layoffs.

Just keep things simple and "remove", "replace", or "cancel" that project. These terms are clear and honest.

9. Cloud

Cloud computing was a huge shift in technology, giving resources on demand, pay-for-use, and distributed globally.

Now the cloud seems to represent any server. Put two servers in your closet, you have a local cloud. Run your application in a container, it's just become cloud-native.

Tech teams have moved to discussing the cloud in specifics, talking about services like k8s or mentioning providers by name like AWS or Azure.

When you see cloud-computing, cloud-native, or just the cloud you can be sure it's a marketing or sales piece.

10. Unplatform

Lately, every software solution has been mislabeled as a "platform". Platforms have a specific definition:

A computing platform, digital platform, or software platform is an environment in which software is executed.

So platforms are where the code is executed, not the software itself. AWS is a platform, iOS is a platform with it's app store. General software is not a platform.

This misuse of the term is irritating, but even worse is any company that uses unplatform. That is just software!

11. ????

Every top 10 list online should have 11 items. There are so many choices for this list it was difficult to narrow it down to 10. So which buzzwords do you find most cringe-worthy? What jargon deserves a place on this list? Add them to the comments.

Subscribe - https://www.youtube.com/JamesLuterek