Adventures in Vibe-Coding with Replit

2025-10-29T00:00:00+00:00

A few weeks back, I tried out Replit Agent to see how viable it is as a development tool. I built two apps from scratch, which took 10–15 hours total, with a decent amount of human input along the way to clarify the agent’s questions.

Project 1: Multi-LLM code review API

The idea for the first project was to have a multi-LLM code review app, where you would pass a repository on GitHub or locally to an API, and it would run several full-repo code reviews, ranking and deduplicating them before returning a response. This setup should allow me to have a web frontend or CLI without much added complexity.

The prompt

Please build an app based on this app specification: app_spec.yaml (460 lines)

The results

After much back and forth (and about 40 agent-generated Git commits), I got this message:

🎉 SUCCESS! The Multi-LLM Code Review Assistant is now fully working!

Well, I actually got this message several times after sending just about any command to the agent. It’s very excited about its own work, even when it doesn’t work! In this case, the API connections were working, and testing with curl gave output, but I couldn’t get it to give more than one code review tip for a large codebase — not a very effective code-review app.

I tried asking the agent to diagnose and fix this:

So, this seems to not be returning very many code review suggestions. If I go
look at the repos I'm putting in, there are plenty of code issues that could be
returned, especially with documentation. How can we make this system find more
issues?

In response, Replit’s agent created a full React frontend for the API! Neat, but far from what I asked — the app still doesn’t return substantial code reviews.

So after ~$100 of agent credits, I found that Replit was not the tool for this app — I’m now trying to build a CrewAI app to accomplish the same thing (stay tuned for a post about that).

Project 2: End Point Ecommerce + Hugo site

A common theme in Replit apps we’ve experimented with is that it prefers to make everything a web app with a React frontend. I was curious how it’d do with a different web stack: The Hugo static site generator for the frontend and our recently launched End Point Ecommerce for the backend.

This is an interesting problem for an LLM, since Hugo is widely used (including on this site), but still small compared to React, Vue, and similar frameworks, and since End Point Ecommerce is well-documented but too new for any online discussion. However, it’s a modern .NET ecommerce framework and the code is readable and straightforward.

The prompt

Build me a hugo website frontend to interact with end point ecommerce:
https://ecommerce.endpointdev.com/

For the UI, make a halloween-themed storefront with orange text, black and grey
backgrounds, and halloween-themed test products. Use the Ballast font for
headers, and charter for body text for now.

After providing this initial prompt, I followed up with these:

Here is the github link for end point ecommerce, which this site will connect to:
https://github.com/EndPointCorp/end-point-ecommerce

Please make the app as simple as possible, while still working

Oh, and please use this demo API to connect to for now, so you don't have to
build any backend at all, just interface with this:
https://demo.ecommerce.endpointdev.com/swagger/index.html

The results (version 1)

It generated a nice, simple ecommerce storefront, using Hugo and End Point Ecommerce. Impressive! However, there’s one red flag: if you look at the products in the demo API we’re using, they are simple groceries — Apple, Banana, etc. So where did “Pumpkin spice treats,” “Spider Web Candy,” and “Ghost Marshmallows” come from?

It turns out, these are “fallback products” Replit had made when it failed to connect to the End Point Ecommerce demo API. Not great for an ecommerce site! Your users would see bogus but real-looking products when they’re unable to see or buy real products (I didn’t test this far, but the site may have even accepted payment info for fake products).

So I followed up:

Please remove the fallback products

The results (version 2)

This looks more promising! We get an error message written by the frontend. In production we might want to display more specific messages based on the response, but for this demo, I’m happy with this way of displaying errors.

In true “vibe-coding” fashion, I asked the Replit agent to diagnose the network error:

There is a network error while loading products, what is the issue?

It responded with a couple options, the main one being assume it’s a CORS issue.

Possible Solutions
Option 1: Server-Side Proxy (Recommended)
- Create a simple server endpoint that fetches the products
- Your frontend calls your server, your server calls the external API
- No CORS issues since server-to-server requests aren't restricted

I was suspicious of it being a CORS issue since everything was hosted in the Replit container, so after poking around myself, I wrote this prompt:

Please use the web api to sign up for an account by POSTing to the /api/User
end point and getting an API key

However, after reviewing the project for this post, I found that I misunderstood the issue in this prompt — no authentication is needed to GET /api/products on the demo API of End Point Ecommerce, the site was just disallowing this cross-origin request. Replit’s agent went ahead and implemented the CORS change anyway, though it didn’t correct my prompt.

After a few more followup prompts…

Please use the "basePrice", "discountAmount", and "discountedPrice" keys that
are returned from the API to show the real prices of the items

Now, please fetch the images from the API as well

…we have a decent working Hugo site connected with the End Point Ecommerce demo API!

Feature addition: cart

I wrote this prompt next, without having done my research on the backend (which made for an interesting unintentional experiment):

Please add a lightweight cart management system which uses localStorage, with
options to add to, remove from, or update quantity of items in the cart. Add a
simple checkout form with contact information, shipping address, and billing
address. For now, instead of payment information, just have a button which adds
a commonly used dummy credit card number.

There’s an issue here: I specified using localStorage, which is a fine way to set up a frontend cart system, but it ignores the existing system End Point Ecommerce already supplies. I hadn’t checked the documentation before making this prompt, and neither did Replit; it happily obliged and created a cart management system on the frontend. It’s nice that the agent did what I asked, but if I were trying to work with the agent, without cross-referencing documentation myself, I would be disappointed.

That’s the interesting part about using a non-deterministic system like AI agents: responding to one prompt, it might ignore my specific (and misguided) requests, but in another it might blindly execute the tasks it’s given. By the nature of LLMs, you can’t predict what you’ll get.

Bonus: a few extra notes

A couple final notes:

No .gitignore was generated, so the Hugo-generated public/ folder is tracked in Git
The agent used plain CSS, without SCSS or a framework — I’d recommend specifying the stack further in the prompt if you want an app that’ll be nice to maintain. You don’t want to assume the agent will make smart coding decisions on its own.

When I’d use Replit (and similar do-it-all AI agents)

I would use Replit for very quick-and-dirty web development, when sites which shouldn’t last a long time — although I’ve seen too many projects originally intended to be short-lived become important for many years…

Replit handles its containerized deployments well; if I needed to share a working demo site within a few hours, Replit would be a good pick. Especially if you like React frontends, even when you might not have asked for one! But if I was dealing with customer data, orders, or my own data I cared about, I would want to be heavily involved throughout the development process.

For projects where performance and accuracy matter (read: most projects), I will be taking a more directed approach. I’ve had some good results using Continue or GitHub CoPilot as a coding assistant for small tasks in existing repos, rather than letting AI taking the wheel completely.

Announcing End Point Ecommerce, Our New Open Source Project

2025-08-21T00:00:00+00:00

Today we’re pleased to announce a new open source project: End Point Ecommerce.

End Point Ecommerce is a minimalist ecommerce system that’s quick to set up and easy to understand. It is meant for developers to own, adapt, customize, and extend.

You can learn more about it on our landing page. You can also fork it today on GitHub. There are running demos here:

Are you interested in using End Point Ecommerce for your ecommerce site? Feel free to contact us and we can work together to help you deploy, customize, and maintain it.

Key features

Built with ASP.NET, PostgreSQL, and Authorize.net
Multiple deployment strategies, including Docker Compose
Code base designed to follow Clean Architecture and Domain Driven Design concepts, without being dogmatic about it — simplicity trumps all
Good test coverage with xUnit
Includes a backend admin portal for managing the store, a REST API for building user-facing store frontends, and a simple web frontend
Limited functionality — implements the bare minimum of ecommerce use cases
Product catalog, shopping cart, order submission, email delivery

How we got here

We recently had the opportunity to help one of our clients migrate their ecommerce site. They were using an established ecommerce engine and were having various problems with it. Their requirements were simple, and they didn’t need all the bells and whistles of big ecommerce solutions. They didn’t want to deal with the overhead, bloat, and difficulty of finding maintainers.

During initial investigation and planning, we didn’t find any options that were small and easy to set up, understand, and customize, so we decided to build them a new site from scratch.

We realize that there may be others out there in the same boat that we were. You want to set up a custom ecommerce site but you don’t want to deal with the complexity of bigger off-the-shelf solutions. You want something which you can thoroughly understand quickly, and modify to your heart’s content, as if it were your own code base that you developed from scratch.

Who is this for?

This project is meant for .NET developers who want a solid and simple foundation to build and customize ecommerce sites. To that end, the feature set is very basic, the code base is very straightforward, and the documentation is very developer-oriented. The idea being that developers can quickly get up to speed with how everything works, develop ownership over the code base, and implement their bespoke use cases.

This project is not meant for non-technical folks. There is no installation wizard, no templating engine, no plugin framework, no no-code customization capabilities.

If you want to set up a simple online store, or develop a highly customized one from scratch, think of this as a way of skipping the first few steps of building the foundational architecture and basic functionality.

Please check it out! And do whatever you want with it!

When to DIY vs Hire for Ecommerce Development

2025-07-01T00:00:00+00:00

A Practical Guide for Business Owners

Many ecommerce businesses start with a scrappy DIY mindset. And that works — until it doesn’t. Knowing when to build it yourself and when to bring in a professional can mean the difference between momentum and mess.

We’ve worked with business owners who built their first site in a weekend — and others who sunk $50,000 into a platform they barely used. Here’s how to figure out which path fits your goals, skills, and budget.

When to DIY (With Confidence)

There are plenty of situations where handling development yourself makes good business sense:

You’re on a tight budget and need proof-of-concept
You’re using simple, user-friendly tools like Shopify, Wix, or Squarespace
You just need a basic store or landing page
You’re comfortable with tech and enjoy learning new tools

Helpful DIY Tools

Shopify
Wordpress / WooCommerce (basic setup)
Webflow
Canva (for design)
Zapier (for automation)

Watch Out For

Mobile layout issues that won’t go away
Slow site speeds or broken checkout processes
Inventory or shipping errors you can’t fix

When the fixes start taking more time than they’re worth — or cost you sales — it’s time to reconsider.

When to Hire a Developer or Consultancy

DIY stops making sense when your business starts scaling or when needs get technical. Here are common triggers:

You need custom integrations — like with an inventory system (e.g., Art of Books), ERP, or POS
Site speed or UX are hurting conversions
You’ve outgrown platform support and need human help, fast
Your time is more valuable elsewhere

Project Types Worth Hiring For

Speed optimization
Custom checkout flows
APconnections (shipping, inventory, accounting)
Multi-language or multi-country setups

Hosting — AWS, Azure, Linode
DNS — Cloudflare
Domains and SSL certificates

If these items are not known to you, consider talking to a consultant.

Pro Tip: You don’t need to hire full-time. Start with project-based freelancers or small consultancies. Good consultancies will bill you on an hourly “as needed” basis. They should also provide estimates for projects that may exceed 5–10 hours.

The Hybrid Approach: Best of Both Worlds

For many business owners, a blended model is ideal:

Have a pro build the foundation — you manage content, products, and marketing.
Use no-code platforms for updates, and freelancers for complex changes.
Set up clear roles — who maintains what, and when to escalate.

What It All Costs

Type	Typical Cost	Best For
DIY	$30–$300/month	Simple stores, startups, testing ideas
Freelancer	$500–$5,000/project	Specific features or upgrades
Consultancy	$3,000–$50,000+	Full builds, scaling projects, business plan integration, ongoing support

Pro tip: Always make sure you have admin access, version control (e.g., GitHub), ownership of code, and documentation if you hire.

Conclusion: Know Your ROI

The right path depends on what gives you momentum without draining your time or wallet.

Don’t hire someone just because you’re tired.
Don’t DIY just because it’s cheap.

The smartest businesses find a rhythm — build what they can, hire when it matters, and stay focused on growth.

Bonus: Quick Self-Assessment

Should you DIY or Hire?

Do you have more time than budget right now?
Are your tech skills good enough for the tools you’re using?
Are bugs and delays costing you money or customers?
Are you trying to integrate systems beyond your experience?

If you answered yes to the first two → DIY may work. If you said yes to the last two → it’s time to bring in help.

Need help evaluating your ecommerce development path?

End Point helps business owners like you balance time, cost, and complexity in ecommerce builds.

Interchange Compression for SessionDB

2025-04-30T00:00:00+00:00

New support for compression of sessions and more lists stored in a RDBMS has been added to core Interchange.¹^,²

A new module, Vend::Util::Compress, operates as a general interface for compressing and uncompressing scalar data in Interchange. The module currently offers hooks for the following compression algorithms:

Zstd (preferred)
Gzip
Brotli

Additional algorithms can be easily added as needed.

Each algorithm depends on the developer having installed the necessary CPAN modules for the given compression type:

IO::Compress::Zstd/IO::Uncompress::UnZstd³
IO::Compress::Gzip/IO::Uncompress::Gunzip⁴
IO::Compress::Brotli/IO::Uncompress::Brotli⁵

Vend::Util::Compress exports compress() and uncompress() on demand. In scalar context, they return the reference to the scalar holding the transformed data. In list context, they return additional measurements from the process.

List compress() returns an array of:

$ref
$before_size
$after_size
$elapsed_time
$alert

List uncompress() returns an array of:

$ref
$elapsed_time
$alert

Any errors encountered when called in scalar context are written to the catalog error log. Errors encountered when called in list context are returned in $alert.

Compression Performance Comparison

The following chart summarizes the results of running the same Interchange instance through several steps of session growth to measure performance and impact of the three supported compression algorithms. Tests ranged from a minimum session size of 68 kilobytes up to a maximum of 110 megabytes. Fields marked in green indicate the best performance of the particular parameter, across all algorithms, for each given session size. Any fields marked in yellow indicate performance measurements reaching a level of concern. Any fields marked in red indicate measurements reaching a level of unacceptable performance in any typical situation.

For size reduction, all 3 algorithms produced a substantial decrease across the board, generally exceeding 90% and increasing the reduction factor as the session grew. All 3 algorithms also uncompressed the session on retrieval at comparable rates, well within tolerance. Where we see significant separation is in the time to compress. Zstd is the fastest across the board, but really stands out when working with larger sessions, when the impact of compression is most needed for reducing transfer latency between the Interchange and database servers.

Configuring Your Catalog to Use Vend::Util::Compress

To begin using session compression, add the new catalog configuration parameter, SessionDBCompression, set to one of the aforementioned compression algorithms. Note the values for specifying compression type to use are case-sensitive. For example, to enable Zstd:

SessionDBCompression Zstd

An empty value for the parameter bypasses compression. An invalid value logs an error and passes through the data unmodified. If the catalog is configured for file-based sessions, the setting has no impact.

The same compression applies to both sessions and more lists when MoreDB is also set.

References

Interchange 3rd Party Tax Support

2023-03-21T00:00:00+00:00

New 3rd-party tax API support has been added to core Interchange¹.

In the wake of the Wayfair court decision², many businesses running Interchange catalogs lack the necessary tools for full compliance. A new translation layer has been created in Vend::Tax to connect the standard sales tax structures and routines that operate within Interchange, and the development of vendor-specific 3rd-party tax providers. The goal of the Vend::Tax framework is to create a space to allow for development of any number of vendor-specific tax services to support tax calculation in Interchange.

Vend::Tax defines 3 new tags to support its function:

[tax-lookup]: Returns calculated tax amount determined by specific 3rd-party provider. Tax may be estimated or live lookup, depending on settings. Data required to calculate tax will be provider dependent.
[load-tax-averages]: Requests and stores tax averages for running in estimate mode, for providers that support it. Stores estimates by default in the tax_averages table. Further, allows for local tracking of jurisdictions with nexus, which can be used by live lookups to determine if a particular lookup can be skipped entirely. See load_tax_averages Job and tax_averages table definition in the Strap demo.
[send-tax-transaction]: Reports to provider the resulting tax transaction for a given order, for providers that support it. By default, operates based on transactions.tax_sent field. 0 or empty indicates transaction not reported. 1 indicates transaction successfully reported. -1 indicates an error attempting to report transaction, requiring manual intervention. See send_tax_transactions Job in Strap demo.

Conceptually, Vend::Tax is patterned off of Vend::Payment for payment transactions. It provides the defined interface that Interchange will use, via the 3 tags shown above, but must delegate to vendor-specific implementations through tax gateway modules.

Additionally, connectors have already been constructed for TaxJar³ and Avalara⁴ in core Interchange, so that catalogs can convert to use either of these popular services for calculating their sales tax with an upgrade and a few adjustments to their catalog configuration. Both TaxJar and Avalara provide sales tax calculation, product categorization, and reporting tools that allow merchants to comply with Wayfair and keep their focus on their business.

While currently only TaxJar and Avalara are supported — see Vend::Tax::TaxJar and Vend::Tax::Avalara — Vend::Tax was designed to facilitate and encourage the development of any 3rd-party providers through the creation of new Vend::Tax::<ServiceName> modules. A review of either of the TaxJar or Avalara tax gateway modules should be instructive for the expected interface with the 3 usertags.

For merchants who have, or wish to establish, relationships with other tax providers, they are free to build, or contract with consultants to build, their own provider’s vendor-specific module and use that to back the work performed within Vend::Tax. Any such development projects are encouraged to be submitted for inclusion in Interchange core, giving the merchant and developer the benefit of community improvements and core inclusion on future upgrades.

Configuring Your Catalog to Use Vend::Tax

In order to leverage [tax-lookup] to back the [salestax] tag, use it with the SalesTax directive. For example:

SalesTax  [tax-lookup service=TaxJar]

The service parameter should correspond with the segment of the namespace of the tax gateway module after Vend::Tax. Here, the example enables TaxJar in module Vend::Tax::TaxJar.

If your business requires sufficient customization, the existing tax gateway modules can be subclassed, keeping all your customizations separate from core code and safe from collisions during upgrades. An example of such an expansion to Avalara would be to create module Vend::Tax::Avalara::MyBiz to subclass Vend::Tax::Avalara and change the config setup to:

SalesTax  [tax-lookup service=Avalara::MyBiz]

Additionally, using the Strap setup, you can easily enable TaxJar specifically by setting the following variables in variable.txt:

TAXSERVICE TaxJar
TAXTOKEN [your TaxJar token]
NEXUS_ADDRESS [business address]
NEXUS_CITY [business city]
NEXUS_STATE [business state postal code]
NEXUS_ZIP [business zip]
NEXUS_COUNTRY [business ISO two-letter country code]

For Avalara in Strap, you also would set the TAXSERVICE and NEXUS_ variables, but then set your account API user and password:

TAXSERVICE Avalara
AVALARA_USER [your API user]
AVALARA_PASSWORD [your API password]
NEXUS_ADDRESS [business address]
NEXUS_CITY [business city]
NEXUS_STATE [business state postal code]
NEXUS_ZIP [business zip]
NEXUS_COUNTRY [business iso two-letter country code]

Finally, like the payment modules, in order to make a particular tax service available, it must be required from interchange.cfg. For example:

Require module Vend::Tax::TaxJar

References

Ecommerce customer names with interesting Unicode characters

2021-12-29T00:00:00+00:00

One of our clients with a busy ecommerce site sees a lot of orders, and among those, sometimes there are unusual customer name and address submissions.

We first noticed in 2015 that they had a customer order come in with an emoji in the name field of the order. The emoji was 😏 and we half-jokingly wondered if that was a new sign of fraud.

Over the following 3 years only a few more orders came in with various emoji in customer’s names, but in mid-2018 emoji started to appear increasingly frequently until now one now appears on average every day or two.

Why the sudden appearance of emoji in 2015? It correlates with the rapid shift to browsing the web and shopping on mobile devices. Mobile visits now represent more than half of this client’s ecommerce traffic.

Most people in 2015 didn’t even know how to type emoji on a desktop or laptop computer, but mobile touchscreen keyboards began showing emoji choices around that time, so the mobile explanation makes sense. And mobile keyboard autocorrect also sometimes offers emoji in addition to words, making them even more common in the past few years.

Just for fun I wanted to automatically find all such “interesting” names, so I wrote a simple report that uses SQL to query their PostgreSQL ecommerce database.

To preserve customer privacy, names shown here have been changed and limited to a few names that are common in the United States.

Real names with bonuses

First let’s look at the apparently real names with emoji and other non-alphabetical Unicode characters mixed in:

Amy 🩺
Amy💕
Amy👑
👸Amy
Anna 💫
Anna 😎
Anna ❤️
Anna💊💉
Bob☯️
Bob😍😘😜👑💞
Bob🐞
Brenda 🌙
Brenda 🥳🤪
Brenda☠️
B R E N D A 💕💅🏾💃🏾👜
Cameron 🌻
Cameron 😎
Cameron 💁🏻‍♀️
Doug 💕
Doug 🅱️
Doug 🌸🤩
Doug 👦🏻❤️
Emily 🌷
Emily 😊🇨🇺
Emily😚
Emily 🎰👑❤️
Frank 🥰
Frank ⚗️
Frank🔆
Frank💞💰
Jane 💕
Jane⁸
Jane ❤️❤️
Jane🔆
Jill 👑🎀
Jill 👼🏽✨🌫
Jill🍓🍒🍒
Jill👸🏽💖
Jim 🐰
Jim, 💕
Jim’s iPhone✨
Joe 🐯
Joe 🇦🇺
Joe😏
Joe🏀🎸‼️
John 👪
John⁵
John🎭
Karen 🌻🌹
Karen 👑✨
Karen 🔒❤️
Karen🎀👑
Kate💙💚
Kate🤪🤞🏽💙
Kate.💘
K$ate💉
Liz🌺
Liz❣️
Liz❤️🙃
Liz Mama💙💙
Mary 🎀
Mary💘
Mary👼🏼💓
Mary⁹
Mike 👑
Mike 👑🌸
Mike 👩🏻‍🌾
Mike⁶
Sarah 👑
Sarah👑A.
✨Sarah✨
💛🌻 Sarah
Steve🐑
Steve 🦁
Steve♓️💓
Victoria 🥴
Victoria🌻
V𝚒𝚌𝚝𝚘𝚛𝚒𝚊
V I C T O R I A 🤍

Would you have expected all that in ecommerce orders? I didn’t!

Fake names

Next let’s look at placeholder names with people’s role or self-description or similar:

Amor ⚽️
Babe ❤️
C𝚒𝚝𝚒𝚣𝚎𝚗
Daddy🥴😏
Daddy😘👴👨🙏👨👩👧🙇🏾
Fly High 🕊
Forever 💍💜
Granny 👵🏽
HOME ❤️
Home🏠
Home🏠💜
Hubby🥰
💦Juicy🍑
me!! 💛
mi amor ❤️
Mom💗
Mom♥️
Mom 🐥💛
MOMMY 💗
Myself 😘
Princess👑
princess❤️
Queen 😍💖🔓
Queen💘
The Husband💍❤️
Wifey 😈✌🏽👅

Perhaps the occurrence of “home” several times reflects a mobile address book auto-fill function for billing or shipping address fields?

Not names at all!

Then there are those customers who didn’t provide any kind of name at all, just emoji and other special characters:

🦋
💙
🤡🎪
💗☁️
🍌
♥️
🌙
⁵
∅

I guess only one or two of those per year doesn’t amount to much, but they’re interesting to see.

Strange addresses

In addition to the name fields we also checked the address fields for unusual characters and found (again, details changed to preserve privacy):

125 E 27😎
227 W 24 Circle ⭕️
3 Blvd. George Washington™

Simply odd

The prizewinner for oddity, which seems like some kind of copy-and-paste mistake, is this in the city field of an address:

Indian® Roadmaster™ Classic

Maybe at least one motorcycle has achieved sentience and needed to do some online shopping!

“Interesting” Unicode ranges

When searching for interesting Unicode ranges, we could just look for characters in the Unicode emoji ranges. That would be fairly straightforward since there are just a few ranges to match.

But we were curious what other unusual characters were getting used aside from emoji, so we wanted to include other classes of characters. So perhaps we should include everything to start and then exclude the entire class of Unicode “word characters”? That covers the world’s standard characters used for names and addresses, including not just Roman/Latin with optional diacritics, but also other character sets such as Cyrillic, Arabic, Hebrew, Korean, Chinese, Japanese, Devanagari, Thai, and many others.

PostgreSQL POSIX regular expressions include the class “word character” represented by either [[:word:]] or the Perl shorthand \w. I started with that, but found it covered too many things I did want to see, such as the visually double-width Latin characters that are part of the Chinese word character range, and some special numbers.

So I switched back to matching what I want, rather than excluding what I don’t want, and I manually went through the Unicode code charts and noted the ranges to include.

The list of Unicode code ranges I came up with, in hexadecimal, is:

250-2ba
2bc-2c5
2cc-2dc
2de-2ff
58d-58e
fd5-fd8
1d00-1dbf
2070-2079
207b-209f
20d0-2104
2106-2115
2117-215f
2163-218b
2190-2211
2213-266e
2670-2bff
2e00-2e7f
2ff0-2fff
3004
3012-3013
3020
3200-33ff
4dc0-4dff
a000-abf9
fff0-fffc
fffe-1d35f
1d360-1d37f
1d400-1d7ff
1ec70-1ecbf
1ed00-1ed4f
1ee00-1eeff
1f000-10ffff

Those ranges exclude several fairly common characters that people (or their software’s autocorrect) used in their address fields, which we wanted to ignore, such as:

Music sharp sign: ♯ (instead of # before a number)
numero: №
care of: ℅
replacement character: � (though this could be interesting if it reveals unknown encoding errors)

The SQL query

PostgreSQL allows us to represent Unicode characters in hexadecimal numbers as either \u plus 4 digits or \U plus 8 digits. So the character 2ba is written in a Postgres string as \u02ba and the range fffe-1d35f is written in a Postgres regex range as [\ufffe-\U0001d35f].

With a little scripting to put it all together, I came up with:

SELECT order_number, order_timestamp::date AS order_date,
    fname, lname, company, address1, address2, city, state, b_fname, b_lname, b_company, b_address1, b_address2, b_city, b_state, phone
FROM orders
WHERE concat(fname, lname, company, address1, address2, city, state, b_fname, b_lname, b_company, b_address1, b_address2, b_city, b_state, phone)
    ~ '[\u0250-\u02ba\u02bc-\u02c5\u02cc-\u02dc\u02de-\u02ff\u058d-\u058e\u0fd5-\u0fd8\u1d00-\u1dbf\u2070-\u2079\u207b-\u209f\u20d0-\u2104\u2106-\u2115\u2117-\u215f\u2163-\u218b\u2190-\u2211\u2213-\u266e\u2670-\u2bff\u2e00-\u2e7f\u2ff0-\u2fff\u3004\u3012-\u3013\u3020\u3200-\u33ff\u4dc0-\u4dff\ua000-\uabf9\ufff0-\ufffc\ufffe-\U0001d35f\U0001d360-\U0001d37f\U0001d400-\U0001d7ff\U0001ec70-\U0001ecbf\U0001ed00-\U0001ed4f\U0001ee00-\U0001eeff\U0001f000-\U0010ffff]'
    -- limit how many years back to go
    AND order_timestamp > (SELECT CURRENT_TIMESTAMP - interval '3 years')
    -- exclude any order that had PII expunged for GDPR
    AND expunged_at IS NULL
ORDER BY order_timestamp DESC

Try a similar query on databases you have access to, and see what interesting user submissions you discover. I always find surprises and in addition to being fun, sometimes we find things that help us improve our input validation and user guidance so that more mistakes are caught when they’re easy for the customer to correct.

Happy holidays!

Our Vue Storefront “Proof of Concept” Experience

2020-08-10T00:00:00+00:00

Recently we experimented internally with integrating Vue Storefront and Magento 2.3. Vue Storefront is an open source Progressive Web App (PWA) that aims to work with many ecommerce platforms.

What initially piqued our interest was the possibility of integrating Vue Storefront with the venerable ecommerce back-end platform Interchange, which many of our clients use. Vue Storefront’s promise of ease of integration with any ecommerce backend made us curious to see whether it would make a good modern front-end for Interchange.

Since Vue Storefront seems to be most commonly used with Magento, we decided to start our experiment with a standard Vue Storefront/Magento 2.3 proof-of-concept integration.

PoC of Vue Storefront/Magento 2.3

OK, to be honest, at the beginning we blindly expected that Vue Storefront would be a copy/paste front-end template solution that would fairly easily be made to work with its standard integration to a Magento backend. Sadly, this was not the case for us.

Before beginning our journey here, to summarize the Vue Storefront integration with Magento let’s have a look at this diagram to see what components are included:

Figure 1

At first, we wanted to see how all these components can be installed and run on a single server with modest resources.

I walked through the Vue Storefront documentation and a few blog posts to figure out Vue Storefront and Magento integration.

Preparing the Environment

I downloaded and installed the following:

OS: CentOS Linux 7 (64-bit)
PHP 7.2.26
Magento 2.3 with sample data
Elasticsearch 5.6
Redis
Docker
Vue Storefront API
Vue Storefront
mage2vuestorefront bridge

Installation of those components is fairly easy. We started our virtual server with 4 GB of memory, which we thought should be plenty for a toy setup.

Indexing Elasticsearch with mage2vuestorefront

PHP and Magento 2.3 had a series of memory usage issues. While running the mage2vuestorefront indexer Magento used most of the memory and caused Elasticsearch to go down each time I tried to index Elasticsearch. Then I configured PHP and Apache httpd server to use a very modest amount memory and made Magento 2.3 work on this server without making it crash due to unavailable memory but the performance became a nightmare on the PHP & Magento 2.3 side. mage2vuestorefront ran without issue, but very slowly.

I am not very familiar with the Magento 2 API, but while indexing Elasticsearch with mage2vuestorefront it makes several individual API calls. Especially if you have several products in Magento 2, mage2vuestorefront calls the Magento API for almost all products. Due to PHP and Magento’s high memory usage available memory might become a problem during indexing.

The Vue Storefront developers explain a big reason why they chose Elasticsearch as one of the essential components of this integration:

Vue Storefront defines itself backend-agnostic PWA e-commerce solution where Vue Storefront is a storefront as the name dictates, and Elasticsearch works as a datastore for catalog and its sibling data such as taxrule, products and so on.

I am unsure if the backend-agnostic approach even really applies to the suggested implementation of Vue Storefront with Magento 2, or if does apply with significant headaches. I’ll detail my concerns about this later.

Viewing the Vue Storefront Application

The responsive and offline supportive design of Vue Storefront is elegant. It uses Elasticsearch via vue-storefront-api as its indexing search engine to provide a seamless user experience. Although the overall integration and the produced data structure looks complex there are only a few catalog data stores that need to be indexed on Elasticsearch. Also, since this is an ecommerce integration, you can expect that only products and product-related data are going to be available in such an integration.

In the Vue Storefront and Vue Storefront API app home directories (vue-storefront/ and vue-storefront-api/) I ran npm start to start the Node.js apps, then navigated to the Vue Storefront homepage to view its default template:

Figure 2

There is a hamburger menu in the top-left which opens the categories menu of Vue Storefront:

Figure 3

As I mentioned, the data being viewed is relatively simple according to the count of the catalog types (essentially Products, Categories, Attributes, and Tax Rules) which are already categorized and these are a bunch of specific sets of data.

By searching through the categories Women > Tops > Jackets, the search output list is shown by Vue Storefront:

Figure 4

Designing a New Approach for Interchange

When exploring the features and components of Vue Storefront we discussed how we can adapt Interchange to use Vue Storefront. We ended up with two main options:

Keep the same approach of Vue Storefront’s current integration with Magento and other ecommerce backends using Elasticsearch and vue-storefront-api as the backend gateways
Remove the Elasticsearch and vue-storefront-api dependencies and create a new API in Interchange producing similar API outputs to the ones vue-storefront-api & Elasticsearch are creating. I also found a similar approach where they integrated SAP Hybris with Vue Storefront. I thought that this way would fit our intention.

Inspired By A Similar Approach of Vue Storefront + SAP Commerce

Vue Storefront + SAP Commerce: Open-source PWA Storefront Integration (+DEMO)

This article discusses several approaches, including Vue Storefront developers’ boilerplate integration and their custom solutions. In the following table they show different options and comments on their resolutions.

Figure 5

As you can see in Figure 5, they decided to go with the 4th option as their most suitable and least problematic solution. Here is their statement of why:

After some analysis, we have come to believe that using custom middleware only for a bunch of simple requests is an additional burden and thick layer of complexity. We decided to get rid of it as well.

So, option #4 turned out to be the best choice. For the option #4, we need to parse Magento and Elasticsearch APIs and generate the compatible responses.

Here is how their solution looks according to option #4:

Figure 6

Using this approach, they decided to remove the Elasticsearch and Vue Storefront API components from the Vue Storefront boilerplate integration and developed their SAP Commerce custom Vue Storefront API to produce responses similar to the responses taken from Elasticsearch through Vue Storefront API to pretend that Vue Storefront is taking its responses from Elasticsearch API + Magento API.

We decided to discard Elasticsearch when integrating Interchange with Vue Storefront for simplicity, and to cut down on the cost such additional search solutions create.

After our discussions, I was inspired by this SAP Commerce + Vue Storefront integration demo. We finally decided to move forward with creating an Interchange API to produce the similar responses to those from the Elasticsearch & Magento APIs, so we could make the Interchange API pretend to be the Elasticsearch API + Magento API.

We need to mention the Magento 2 API, or at least the Magento 2 data structure, because the Vue Storefront API and Vue Storefront boilerplate code is heavily designed to be taking ecommerce data (Products, Categories, Product Attributes, Tax Rules etc.) almost identical to the Magento API’s provided data.

So our Interchange + Vue Storefront integration looks like this:

Figure 7

Compare Figure 1 with Figure 7 to see the difference between this approach and Vue Storefront’s suggested solution.

Interchange API Prototype Design

In order to achieve the API prototyping for our Interchange/Vue Storefront integration, I cloned vue-storefront and vue-storefront-api, which I had previously integrated with Magento 2.3, into a new user, keeping all settings the same. This cloned Vue Storefront application started initially with the same configuration as vue-storefront-api and Elasticsearch were not excluded yet. So I decided to replace the vue-storefront-api endpoints that vue-storefront is calling with endpoints from the new Interchange API.

As the default SAP Commerce/Vue Storefront integration suggests, I walked through the outputs of search results in “product”, “category”, and “attributes”. Product data JSON output has some universal attributes like name or title, description, or price, but it also has some custom product attributes adapted from the Magento 2 API (specifically, the data structure of Magento is applied).

At this point I started questioning if Vue Storefront is not really platform agnostic, or if it is, but with some headaches. The next section will detail these headaches but to summarize, adapting the data structure of new ecommerce backends to Vue Storefront is a real pain. It forces you to use its data structure since that’s a part of core development, and they rely mainly on Elasticsearch, and I guess because of that the developers of Vue Storefront believe that Elasticsearch is an essential part of this “agnostic” approach. Refer to Getting data from Elasticsearch for custom implementations using the core Elasticsearch lib.

Anyway, I moved on and produced product and product categories outputs that Vue Storefront expects as the search results at the homepage and the search box output results.

Documentation is another pain. This is discussed further in the next section, but briefly, it’s hard to say that you could clearly pick the data structure that all kind of output results from the documentation. You need to dig into the TypeScript code, and the exact search output result is what is actually being expected.

One conflict was that the identifiers are required to be numeric, not strings. If your ecommerce data structure doesn’t provide its identifiers as numbers you’ll need to alter and add a new numeric unique identifier along with the existing one, which is what I did.

Product attributes also need to be adapted to Vue Storefront (really to Magento’s data structure). The attribute names, attribute lists, attributes’ assigned values, and categories attached to the products and configurable child products all come along with the product list on a search output. If your ecommerce data is not structured similarly to Magento’s data structure, you need to dig and restructure even for minimal changes like product attributes and configurable child products. For example, if your data structure doesn’t allow configurable child products then you can probably only provide each option (such as product color or size options) as a new product, which will be a real pain.

Most of Vue Storefront’s app endpoints are defined in config/default.json which is the default config on a new install. On the other hand, the ecommerce catalog data (which is indexed in Elasticsearch) is available through the Elasticsearch implementation which is by default defined in lib/search/adapter/api/searchAdapter.ts. In my case I needed to alter this implementation, which is generating the Elasticsearch (actually the Vue Storefront API) endpoints dynamically by looking up the related catalog index (product, category, attributes, taxes, etc.), and change the Elasticsearch definition in the Vue Storefront config file to the new Interchange API, adapted to emulate the Vue Storefront API and Elasticsearch:

...
  "elasticsearch": {
    "httpAuth": "",
    "host": "/api/catalog",
    "index": "vue_storefront_catalog",
...

I needed to set the Interchange API URL to the host property and not necessarily set an API-defining URL sub-path name to the index property above. This way our API would pretend to be the Elasticsearch endpoint as long as it can generate the JSON output that Vue Storefront expects.

These configuration changes generally satisfied Vue Storefront’s expectations.

Common and Exceptional Issues

Many concerns and challenges are discussed in this article on Vue Storefront + SAP Commerce integration which I mentioned earlier.

A review of some issues I detailed earlier:

Required numeric unique IDs for all catalogs (products, categories, etc.)
Poor documentation
Catalog data structure is managed on the Vue Storefront side, heavily relying on its own data types and models. Your backend may need to be adapted to meet Vue Storefront’s expectations, even if you are using Elasticsearch.
A structure which is constantly being reorganized, creating a big maintenance concern.

Conclusion

Despite my concerns, I thought we could still implement our Interchange API with a front-end framework, but I hadn’t asked the question: Is it reusable enough to mantain? Each of our clients would have different UI and UX expectations. One UI template model could never be enough, which would mean continuous front-end template design and enough maintenance to match the operational cost of existing Interchange front-end solutions. Adapting existing data to Vue Storefront’s new data model would bring more costs along with it.

While Vue Storefront’s offline working model is well designed, for the purpose of integrating with a non-Magento backend, this is overshadowed by its many issues. You would be better off looking elsewhere for a more modular, truly platform-agnostic, easier-maintained, component- and data model-independent front-end.

Magento 2: Creating a custom theme

2020-06-24T00:00:00+00:00

Photo by Maria Eklind, CC BY-SA 2.0

In my previous post, we went through the steps needed to create a custom module in Magento 2. While modules consist of a set of classes to add new features to Magento, a theme controls how these features, and the entire website in general, will be displayed to the user. As stated in the Magento guide, a theme uses a combination of custom templates, layouts, styles, and images to provide a consistent look and feel across a Magento store.

Creating a new Magento 2 theme

We can create a theme based on a default “parent” theme or create a standalone theme from scratch. In most cases, I would recommend the first option. For this example, we will use Luma as our parent theme. The other option would be inheriting from the default “blank” theme.

Here’s an initial task list to get our new theme ready:

Create a new directory for the theme
Create the registration.php script
Create the theme.xml information file
Activate the new theme

Creating a new directory for the theme

While all our backend code should go in app/code, the frontend content is expected to go in app/design. And as our theme will only apply design changes to the frontend content, we should create the new directory for it under the path app/design/frontend. If we want to create a theme for the admin area instead, we need to create the directory inside app/design/adminhtml.

Let’s create a directory named EndPoint (our vendor name, continuing with the example from our previous article) and a subdirectory inside it, MyTheme:

cd {website_root}
mkdir -p app/design/frontend/EndPoint/MyTheme

Creating registration.php

Similar to the file we created for our module, registration.php tells Magento to register the new theme with the name and location we specify. Our file will be located at app/design/frontend/EndPoint/MyTheme/registration.php and should have the following content:

<?php
\Magento\Framework\Component\ComponentRegistrar::register(
    \Magento\Framework\Component\ComponentRegistrar::THEME,
    'frontend/EndPoint/MyTheme',
    __DIR__
);

This way, Magento will know what path our theme will have.

Creating theme.xml

The next step is to create our theme information file, where we will specify the theme name and parent theme. So our app/design/frontend/EndPoint/MyTheme/theme.xml file should have the following content:

<?xml version="1.0"?>
<theme xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Config/etc/theme.xsd">
    <title>MyTheme</title>
    <parent>Magento/luma</parent>
</theme>

Optional: If we want our theme to be easily distributed as a package, we can also create a composer.json file in the theme’s root directory. The content for the file should be as follows, specifying the theme’s description, dependencies, version, and license types:

{
    "name": "endpoint/mytheme",
    "description": "My Theme by End Point",
    "require": {
        "magento/theme-frontend-luma": "100.0.*",
        "magento/framework": "100.0.*"
    },
    "type": "magento2-theme",
    "version": "100.0.1",
    "license": [
        "OSL-3.0",
        "AFL-3.0"
    ],
    "autoload": {
        "files": [
            "registration.php"
        ]
    }
}

Activating our new theme

That was easy! We have everything we need to activate our new theme. To do that we log in to our admin area and enable our theme. Once in the dashboard, we need to go to Content > Design > Configuration, edit our store view, and select our new theme from the dropdown list:

Magento will search for new themes every time we log in to the admin area, so our new theme will appear on the list automatically.

Adding custom content

We have the basic structure for our theme, but when enabled, it will look the same as its parent theme (Luma, in this case), since we didn’t add any design rules or static files yet. Let’s do some more things with our theme to change how it’s displayed in the frontend:

Create a custom etc/view.xml file
Add a custom logo
Add static files (JavaScript, CSS, images, fonts)
Add a custom layout

Creating a custom view file

etc/view.xml controls many frontend configurations like the product thumbnail width, how the product image gallery is displayed, and the image magnifier tool, among other things. To add our custom view file to our theme, we need to copy the existing file from our parent theme. For Luma, it will be located at vendor/magento/theme-frontend-luma/etc/view.xml. To copy the file, we need to run the following in our website’s root:

mkdir -p app/design/frontend/EndPoint/MyTheme/etc
cp vendor/magento/theme-frontend-blank/etc/view.xml app/design/frontend/EndPoint/MyTheme/etc/view.xml

And then we can use our preferred text editor to change the values we want, like setting a custom size for the images in the category page grid:

<image id="category_page_grid" type="small_image">
    <width>300</width>
    <height>300</height>
</image>

Adding a custom logo

Adding a logo to our theme is really simple. We just need to save our picture in SVG format as web/images/logo.svg. If we want to use a different filename or format for our logo, we will have to create a default layout file for our theme in the path /Magento_Theme/layout/default.xml inside our theme root with content similar to this:

<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
  <body>
    <referenceBlock name="logo">
      <arguments>
        <argument name="logo_file" xsi:type="string">images/custom_logo.png</argument>
        <argument name="logo_width" xsi:type="number">300</argument>
        <argument name="logo_height" xsi:type="number">200</argument>
        <argument name="logo_alt" xsi:type="string">Custom logo name</argument>
      </arguments>
    </referenceBlock>
  </body>
</page>

We can use different image formats such as SVG, PNG, or JPG. We can also use a custom width and height for the logo, and set a custom alternate text.

Adding static files (JavaScript/CSS/images/fonts)

All the static files should be located inside the web directory. Common static files include JavaScript files, stylesheets, images, and fonts. The JavaScript files should be located at web/js, stylesheets at web/css, images at web/images, and our custom fonts should be located at web/fonts.

All the static files will be published as direct links, without any processing from Magento, at the pub/static/frontend/EndPoint/MyTheme/en_US path. The default locale/language is en_US; we can change it for our theme if needed.

Adding a custom layout

Finally, if we want to use the new assets we added and have custom content on different sections of our website, we need to extend or override the existing layout files from our parent theme.

For example, if we want to add a reference to new stylesheet and JavaScript files we added, we need to extend the existing header layout from our parent theme. To do this, we will create a new layout file located at Magento_Theme/layout/default_head_blocks.xml:

<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
  <head>
    <!-- Custom stylesheet -->
    <css src="css/mytheme.css"/>

    <!-- Custom JavaScript -->
    <script src="js/mytheme.js"/>
  </head>
</page>

This way we will be adding a reference to a new stylesheet named mytheme.css that we have inside the web/css directory of our theme, and a new script named mytheme.js inside the web/js directory.

After we make all the desired changes to our theme, we will need to tell Magento to update the frontend. We need to deploy the new changes and clear the cache. We can achieve that by running this from our website root:

php bin/magento setup:static-content:deploy
php bin/magento cache:clean

This process can take some minutes to complete. After it’s done, we can go to our website to see if the frontend changes are applied:

Looks awesome! Of course, there’s a lot more we can do from there, from extending or overriding layouts from modules (Magento or third-party) to bundling scripts or using Less files for our custom styles. But, that is material for later posts, so that’s all for now! Please add any questions you might have below.

Shopify Admin API: Importing Products in Bulk

2020-05-04T00:00:00+00:00

Photo by Chris Young, used under CC BY-SA 2.0, cropped from original.

I recently worked on an interesting project for a store owner who was facing a daunting task: he had an inventory of hundreds of thousands of Magic: The Gathering (MTG) cards that he wanted to sell online through his Shopify store. The logistics of tracking down artwork and current market pricing for each card made it impossible to do manually.

My solution was to create a custom Rails application that retrieves inventory data from a combination of APIs and then automatically creates products for each card in Shopify. The resulting project turned what would have been a months- or years-long task into a bulk upload that only took a few hours to complete and allowed the store owner to immediately start selling his inventory online. The online store launch turned out to be even more important than initially expected due to current closures of physical stores.

Application Requirements

The main requirements for the Rails application were:

Retrieving product data for MTG cards by merging results from a combination of sources/APIs
Mapping card attributes and metadata into the format expected by the Shopify Admin API for creating Product records
Performing a bulk push of products to Shopify

There were some additional considerations like staying within rate limits for both the inventory data and Shopify APIs, but I will address those further in a follow-up post.

Retrieving Card Artwork and Pricing

I ended up using a combination of two APIs to retrieve MTG card data: MTGJSON for card details like the name of the card and the set it belonged to, and Scryfall for retrieving card images and current market pricing. It was relatively easy to combine the two because MTGJSON provided Scryfall IDs for all of its records, allowing me to merge results from the two APIs together.

Working With the Shopify Admin API in Ruby

The Shopify Admin API deals in terms of generic Product records with predefined attributes like title and product_type. The official shopify_api Ruby gem made it very easy to connect to my client’s Shopify store and create new products by creating Shopify::Product objects with a hash of attributes like so:

  attrs = {
    images: [{ src: scryfall_card.image_uris.large }],
    options: [
      {
        name: 'Card Type'
      },
      {
        name: 'Condition'
      }
    ],
    product_type: 'MTG Singles',
    tags: card.setCode,
    title: card.name,
    variants: [
      {
        inventory_management: 'shopify',
        inventory_quantity: 1,
        option1: 'Foil',
        option2: 'Like New',
        price: scryfall_card.prices.usd_foil
      }
    ]
  }

  Shopify::Product.new(attrs).save

The actual production code is a bit more complicated to account for outliers like cards with multiple “faces” and cards that come in both regular and foil variants, but the example above shows the basic shape of the attributes expected by the Shopify API.

Pushing 50,000 Products to Shopify

After I completed testing with individual products and confirmed the ability to take a specific card and turn it into a Shopify product with artwork and pricing pre-populated it was time to perform the full upload of all 50,000+ cards in the MTGJSON database. I decided to use Sidekiq and create jobs for each card upload so that I could rate limit the workers to stay within rate limits for both the Scryfall and Shopify APIs, and also have persistence that would allow me to pause/resume the queue or retry individual failed jobs.

The Sidekiq approach to queueing up all of the card uploads worked great; I was able to use the Sidekiq dashboard to monitor the queue of 50,000 jobs as it worked its way through each card, and was able to see the Shopify products being created on the store in real time. Once the inventory was in place in Shopify the store owner was able to start updating his inventory levels and make cards available for sale via the Shopify Admin.

Conclusion

A custom Ruby application using the Shopify API is a powerful solution for online storefronts that need to retrieve a large number of inventory data from external sources. I was pleased with how this project turned out; it was rewarding to create a custom application that leveraged several APIs and automated a task that would have been extremely repetitive, and probably impossibly time-consuming, to do manually. It was encouraging to do my first upload of a card and see it show up on the Shopify store with artwork, pricing, and card details pre-populated.

The development model used for this project could be applied to stores in a wide variety of markets. This project used external APIs to retrieve product information but that data source could easily be replaced with a spreadsheet, CSV file, or some other export file containing bulk information on products to be sold.

Magento 2: Creating a custom module

2020-04-01T00:00:00+00:00

Photo by Babatunde Olajide, cropped from original

A Magento module is a set of classes and routines that will depend on and interact with other Magento classes in order to add a specific feature to a Magento application. While a theme is orientated towards the front-end and user experience, a module is orientated towards backend logic and application flow.

We will need to create a custom module if we want to add or change the existing logic at a level where Magento doesn’t provide a setting or option for it. For example, if our business has a specific feature or set of features or requirements that are not common to the market, a module can fill that gap for us.

Creating a basic Magento 2 module

Creating a simple module in Magento 2 is not that hard. We will need to accomplish the following tasks:

Create a new directory for the module
Create a registration.php script
Create a etc/module.xml information file
Install the new module

Creating a new directory for the module

Where should the new directory for our module be placed? We have two options to choose from:

app/code/{vendor}/
vendor/{vendor}/

If your module is intended for a specific website you’re working on, you can use the first option. If you’re creating a module with the intention of it being used on several websites, it’s best to choose the second option. We’ll use the first for this example.

Let’s create a directory named EndPoint (our vendor name) with a subdirectory inside it, MyModule:

cd {website_root}
mkdir -p app/code/EndPoint/MyModule

Creating the registration.php script

The registration.php file tells Magento to register the new module under a specific name and location. Let’s create a file named app/code/EndPoint/MyModule/registration.php with the folllowing content:

<?php
\Magento\Framework\Component\ComponentRegistrar::register(
    \Magento\Framework\Component\ComponentRegistrar::MODULE,
    'EndPoint_MyModule',
    __DIR__
);

We’re telling Magento that our module will be named EndPoint_MyModule.

Creating the etc/module.xml information file

Now, let’s create our module information file, where we’ll specify the module version number. First, we need to create the etc directory inside app/code/EndPoint/MyModule:

mkdir app/code/EndPoint/MyModule/etc

then create module.xml with the following content:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="EndPoint_MyModule" setup_version="1.0.0">
    </module>
</config>

Installing the new module

That’s it! We have everything we need to install our new module. Now we need to tell Magento we want to install and enable our new module. So from our website root we need to run:

php bin/magento setup:upgrade

Magento will output a list of module names and configuration updates, and our new module EndPoint_MyModule should be listed in that output.

Adding a custom route to our module

Now we have a working, enabled module, but it’s not doing anything yet! What’s a simple way to check that our module is enabled? Let’s set up a custom route, so if we hit a URL like https://{our_website}/mymodule/test/helloworld we can return a custom response from a controller.

Creating a custom route will need some steps on its own:

Create a new directory for the controller
Create a etc/routes.xml file
Create the controller
Upgrade the new module

Creating a new directory for the controller

First we need to create a new directory where the new PHP controller for our custom route will live. The new directory path should be:

app/code/EndPoint/MyModule/Controller

We can create as many directory levels we want, depending on our desired path. For example, if we create a class named Index in app/code/EndPoint/MyModule/Controller, the URL that will be routed to this controller will be https://{our_website}/mymodule/index (the “Controller” directory is ignored). If we create a class named HelloWorld in app/code/EndPoint/MyModule/Controller/Test, the resulting URL will be https://{our_website}/mymodule/test/helloworld.

Creating the etc/routes.xml file

routes.xml will tell Magento what base URL will be used for our module. First, we need to create the “frontend” directory where the routes.xml file needs to be placed:

mkdir app/code/EndPoint/MyModule/etc/frontend

In this example, we want the base URL to be MyModule, so we need to create an XML file inside the new directory that will route all requests made to the given URL to our module controllers:

<?xml version="1.0" ?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:App/etc/routes.xsd">
    <router id="standard">
        <route frontName="mymodule" id="mymodule">
            <module name="EndPoint_MyModule"/>
        </route>
    </router>
</config>

Creating the controller

If we want to respond to requests for https://{our_website}/mymodule/test/helloworld we first need to create the base Controller directory and the Test subdirectory:

mkdir -p app/code/EndPoint/MyModule/Controller/Test

Under this directory, we’ll create our custom Magento controller. All route controllers should extend \Magento\Framework\App\Action\Action. We also need to have a public construct() method to pass the context to our ancestor and an execute() function that will be called when the URL is hit:

<?php

namespace EndPoint\MyModule\Controller\Test;

class HelloWorld extends \Magento\Framework\App\Action\Action
{

    public function __construct(
        \Magento\Framework\App\Action\Context $context
    ) {
        parent::__construct(
            $context
        );
    }

    public function execute()
    {
        echo "Hello world!";
    }

}

Upgrading the new module

We have everything in place to tell Magento we have new changes to be deployed. How we do that? First, we need to upgrade our Magento setup. But since we added a new controller that gets parameters from the dependency injector in the construct, we also need to compile the dependency injection engine (including factories, proxies, and interceptors). And finally, we need to clear the cache so new content will be served from our custom URL:

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush

This process can take a few minutes to complete, but after it’s done we can try to reach our new custom URL. If we get a response like the one below:

That means our module is working!

That’s all for now. In upcoming posts, we’ll start complicating things a bit by overriding Magento classes with our custom ones and creating custom controllers that will return information from the Magento core classes. We will also explore how to customize the front-end by creating a theme. Don’t forget to add any questions, suggestions, or issues in the comments below!

E-commerce Client Project Management

2020-03-12T00:00:00+00:00

Photo by You X Ventures on Unsplash

Moving from writing code to managing the show

Many times engineers/developers make the move from development to project management. It’s a natural move, we want the folks who know the nuts and bolts of e-commerce projects to eventually manage them.

So that’s all fine and dandy, but what if you haven’t been a “manager” before?

How do you manage an e-commerce client?
How do you manage an e-commerce project?
How do you manage engineers/developers for an e-commerce project?

An answer for each of the above is always: “It depends.” Or maybe more familiarly for Perl developers: TIMTOWTDI.

The reason for that of course is that all of the above questions have variables that will change for every situation.

As a developer, you understand the large number of outcomes that can be introduced into an application by using a single variable. You also understand that the number of outcomes increases proportionally with the number of variables.

The same holds true for management. When you are faced with managing a project, your “variables” now move from placeholders in your code, to placeholders in your project. Where you may have assigned a variable for a “string”, “integer”, or “boolean”, you now may have a “client”, “project”, or “team of developers”.

The point here is that while variables will change from project to project, the “structure” of how you run that project can still remain consistent. Much like designing code to return consistent results while using a wide range of variables.

In order to achieve this type of consistency, the core operations that run within the project, need to be reliable. Over time you will come to develop processes in your projects that will be reliable, and that you will return to time after time, project after project. To get you started, here are a few that should be at the core any project management:

Know your client.
Learn the project.
Know your developers.

These are 3 basic rules that should guide any project, and we will explore each in more detail below.

Now as you can see, each situation will vary widely. A good project manager will understand that any project is multifaceted, and consists largely of human resources.

Let me also note that while this topic is titled “E-commerce Client Project Management”, it could just as easily be titled “Client Project Management”. The principles of project management apply to many different environments.

So if you are new to project management, the first piece of advice I will give is to:

1. Know your client

Everything flows from the client. Always remember, the client is paying you to represent their best interest. This can sometimes mean that you will need to tell the client that you are not the best choice for a particular project!

“Wait…” you will ask, “why would I tell a client to use someone other than me to manage their project? And how would that benefit me? I am in business to manage projects after all!”

I would answer that question with another: How long to you want to be in business as a project manager? If the answer is anything other than “a long time”, you can stop reading now.

Let me give you a quick analogy. Let’s say you went to a car “lot A”, and told the salesman that you needed a very specific type of vehicle because you deliver a highly perishable product. Let’s also assume that this salesperson did not have that specific vehicle on his lot, but that he also knew of another “lot B” where the exact vehicle was sitting. What would you want that salesperson to do? Would you want him to just tell you that they could customize a vehicle on their lot to do most of what you need? Would you want him to refer you to the other dealership?

Or, would you like him to explain all options that he knew of that might apply to your situation? If you chose this last option, score extra points for your potential future as a project manager. To further reinforce this, remember, very few clients only need one project managed.

Ok, so we have established that you need to know your client. That sounds easy, or does it? How do you “know your client”? Let’s try to distill it down a bit. There are many ways of “knowing” someone. We can know their personality, their family, their business, their religion, politics… ok, enough already. But believe it or not, all of the aforementioned points will come into play with a long-term client. But we want to talk about the basics here. We will assume we have a first-time client, with a first-time (to us) project.

Find out about the clients’ business. How do they make money with this business? While you are talking to the client about this, ask questions that get the client to explain and promote their business to you. For most, this will be easy… sometimes to the point of having to learn how to politely stop them! But you will learn far more about their business, and their personal approach to that business by listening than you will by talking.

Just get them started, and let them roll. In the early meetings, ask questions about why and how the client feels their product/service is superior to others. Find out who in the company was responsible for various aspects of the product/service. Learn who the stakeholders are. Try not to ask too many technical questions until the project outline has been defined, and you personally have a good feel for what it is comprised of.

Clients are not free

Clients are a long-term (and ongoing) proposition. Take care of them and they will return again and again. Ignore them and they will respond in kind, and usually very quickly. The time you spend building client relationships is normally non-billable. So keep that in mind the next time a client is hard to deal with and you think “We don’t need clients like this, let’s just find a new one”. You will invest a lot of time and energy with a client. Try not to waste it.

2. Learn your project

If you have a good understanding of the client and their business, you next want them to explain to you what they are attempting to accomplish with this project. Let me clarify here: You do not want them to explain how they want to do a project. You want to first learn what the client wants to accomplish with the project.

This is important, and should be understood completely because if you blow this phase you can easily miss one of the major points of e-commerce project management. I have found that about 7 of 10 clients have major misconceptions about how things actually work in our business. They usually have a very good idea of what they want to have happen in the end, but not so much how to make that happen.

When I say understand completely, I am talking about the 3 of 10 that do know what they are talking about and need to be taken literally.

It will be up to you to determine what type of client you are dealing with. Use your past experiences with people to figure this out. It can be hard. You have to make sure you don’t insult someone’s intelligence, and at the same time you need to know on what level you should attempt to communicate with them. I have found it’s best to let the client talk, try to ask “steering” questions that can unearth what level of experience you are dealing with. These conversations will set the stage for the rest of the project. You will determine how much you will need to supply in the way of structure and advice for the project, as well as give you a clue as to what developers and resources you will use for the project.

Because this post is geared towards developers becoming project managers, I would tell you that this is a place to lean on your background. You should be able to listen to the client, ask the right technical questions, to get a good feel for how you will manage the project.

Once you have figured out how much of what type of role you will have to play in the project, you will need to either define the proposed scope of the project, or examine scope definition given to you by the client. There are many threads that can stem from this, but are not germane in this post, and we can move on to resourcing or how to manage your developers.

Depending on the project, you will most likely need to:

Small project: Just do it once client approves.
Small to medium-small project: Give a ballpark estimate of costs, usually un-billed.
Medium project: Give a more detailed estimate, perhaps billing for estimating time.
Medium to large project: Give a detailed estimate, billing for estimating time.
Large to very large project: Give estimate of time for a formal quote. A quote is in essence a small project on its own.

Again, estimating a project is an art in itself, and is not part of this post.

Normally, in all of the above other than #1, you will need to confer with developers on your team to supply the client with an accurate estimate of costs. Of course, in order to be an efficient PM, you first need to:

3. Know your developers

This should be pretty self-explanatory, but obviously you are not going to put a front-end developer on a code-intensive back-end project.

Another obvious point is that we are talking about a situation in which you have the luxury of multiple developers to choose from. If that is not the case, then you will be faced with another task, that of serving as a “translator” between the client and the developer.

Given that statement, there are nuances that need to be considered when matching developers with clients, or how to control communications.

If the client is a larger company, try to get them to assign a champion for the project, someone who is preferably somewhat technical, has authority to make some level of changes and decisions, and who is appointed by a high-ranking person in the company. This person should be the contact point, representing the client for all daily project decisions and questions. In larger projects, this person may oversee a team from the client, that will interface with your team of developers. Without this person, you should warn the client that undue and excessive delays due to communications will occur.

If the client is a smaller company, try to get an owner or other heavily committed person to be your point of contact who will automatically escalate your questions so that you do not have to wait around for answers. You won’t want to wait for answers, and the owner will not want to pay for your time or lost calendar days to wait for answers either!

All this so far is great, if you are the point of communication for your company. In many cases it will prove to be best for this to happen. You can monitor all conversations, communications, and prevent misunderstandings and hopefully anticipate problems before they occur.

But if you need to have your developers talk directly to the client’s rep, you have some thinking to do. Certain traits do not mix well:

If your client is very opinionated about their project, try to work out directions and methods before allowing communication between developers and client. Use Trello, Slack, etc to assign specific tasks for specific people. Try to track progress of predefined tasks, and limit creation of undiscussed features. Stick to the program; this is not the place for “developer creativity”. This is where you really get tested, you have to know your developers so that you do not create resentment through restraint, but at the same time picky clients will not accept drawing outside the lines.

If your client is tech-savvy, easy to get along with, and you can convince your developers of that, direct interaction can be extremely productive. But don’t just assume this will work. Be on the the first phone calls or video conferences, be a fly on the wall, observe the dynamics. Don’t run the meeting; step in only if necessary.

Use your resources. If you have two front-end people, and you have friction between the client and one of them, introduce the other for a separate task. Observe, did it work out? Do I need to phase out one in favor of another?

If possible never “pull” a developer completely off a project, unless of course it’s requested/required. (Do the words “burning your bridges” sound familiar?)

Always talk to the developer in private about whatever the issue is, and always point out to developers that relationships do not depend on talent alone. What works for one client will not work for the next.

Make sure you know your developers. You need to stand up for them when talking to clients. If you are not comfortable with a developer, you need to either discuss it with a superior, or if you are the superior you need to let them go. You cannot lie to a client about your faith in a developer. Clients don’t want to hear you bad-mouth a developer in your own company — this simply makes you and the developer look bad. The client expects you to have faith in your developer, and to stand up for them.

With that said, back to rule #1, know your client. You have to know what that client will tolerate or expect. You may have to be firm with some clients, so that you can give them what is the best solution for their project.

Other clients may require a soft approach and may completely understand “how this stuff works”. When you get one of those, you will understand very quickly, and be very thankful.

Summary

Managing projects is a challenging proposition. But if you put things in perspective, you will find that it can be simplified and rewarding. Try to keep the big picture in mind as you proceed through the project. It’s easy to get drawn into the details of a project, and sometimes that is what is required. However, if you have good resources available to you, it is up to you to put the areas of responsibility into the proper hands. Coming from development, this will be a real temptation. However, you have a new title now, so put it to work!

Remember, you are not working on this project to create something for you, or your developers. You are creating something for your client. The project’s goals are largely dependent on your clients needs. I am not saying that you cannot create something that you or your developers like, quite the contrary. I am suggesting that by focusing on the needs of the client, and really listening to them, then sharing the expertise of you and your team with the client, you can arrive at something that will not only work extremely well for your client, but also provide you and your team with a great sense of accomplishment.

Ecommerce sales tax primer

2020-01-13T00:00:00+00:00

Co-authored by Greg Hanson

Source image

Tax collection is one of the topics du jour for those of us in the ecommerce industry. Since state and local authorities are now able to levy taxes on ecommerce goods, taxation for online stores has become quite complicated. The purpose of this post is to give you some next steps and ideas on implementation if you’re new to the topic and need to know how to get started on tax collection for your ecommerce business.

Current ecommerce sales tax policy stems from the 2018 U.S. Supreme Court decision South Dakota v. Wayfair, Inc. Since that decision, favoring South Dakota, 30 states have enacted legislation to require ecommerce stores to pay sales tax if they fit the definition of having an ‘economic nexus’, that is, they do enough business in the state to be worth taxing.

Talk to your Tax Accountant

So the first and most important note is to get your own legal counsel in regards to your taxes. There are many rules and things are changing every month with local and state authorities, so you’ll need reliable counsel on the topic.

If you’re looking for someone to help, make sure this person has:

Knowledge about product variants. For example, clothing may not be taxed in some areas.
Familiarity with tax policy in the entire country, and not just one local retail area.
The ability to help you determine in which states you have a tax ‘nexus’ and need to pay sales tax. For many small businesses, you might only do enough business to pay sales tax in your home state and a few large ones like California or New York.

Research Software

Luckily for anyone starting to collect sales tax, there are some very good SaaS (software as a service) systems out there to make tax collection, reporting, and compliance easy. These software systems typically integrate with your ecommerce store by providing the store with the correct tax amount for the sale and collecting information for you on your reports and filing information to get the taxes paid to the correct authorities. Some systems might even file things for you.

After you’ve worked with your tax accountant on what you need, start looking at the available software. The two main companies End Point has worked with are TaxJar and Avalara, though there are a number of other vendors in the market.

Why use an automated tax solution?

They automatically update tax rates as they change with local and state regulation.
They can integrate into your checkout processes via API or plugin to automatically calculate the correct tax for the right location and product.
They can have product-specific taxes, for things that might not be taxed like food and clothing in certain states.
They give you end-of-year reports and help with your payments.
You can customize settings, in case there are some states where you have a ‘nexus’ (are subject to sales tax) and other places where sales tax payments are not required.

What to look for in automated tax software:

Choose a reputable company with large brand presence. You don’t want to do anything experimental and unreliable here.
Pick something with documentation you can understand. You don’t want working with your tax software to be a pain, and you might need to refer to their documentation when configuring it or changing things in the future. Make sure that company speaks your language and you can easily get answers to your questions.
This company should be able to guide you through all aspects of tax collections, filing and payment. You will legally be liable for taxes on all sales in states where you have nexus, whether you collect the taxes or not! So make sure the company you select can work with you not only to set up the system, but on an ongoing basis providing support in filing reports and making payments.
Integration with your platform is a key component of what you choose. Both Avalara and TaxJar have existing plugins for sites running on WordPress, Shopify, BigCommerce, Magento, and others. Keep in mind though that the integration might be different depending on your platform. If you’re on a custom platform, talk to your development team about integrations; they can read the docs and give you an estimate and recommendation for ease of implementation (that’s where we come in for many clients). For Interchange stores, we have integration code for both TaxJar and Avilara to leverage.
Consider how your inventory or ERP system might be affected. Many of our ecommerce clients sell in-house or over the phone. Consider how your other systems might need to tie into this new tax system.

Implementation

So you’ve done the hard part, right? You sorted out what states you need to be compliant with and picked a software solution. Now all you need to do is get it working. This is really where your software consultant, such as us at End Point, would come in and get you to the finish line. The steps to implementation are:

Set up your account and pay for your tax solution software.
Work with the tax solution provider to set up any required bank accounts or payment channels.
Configure your settings.
Share the API key and information with your developer.
Test the implementation. I recommend you do this with several orders in different scenarios: products that do and don’t have sales tax, locations that do and don’t have tax, locations that tax shipping, etc. Test all the variants you know about.
Go live with your tax solution on your site.
Make sure to check back for your reports and filings for later in the year.

Need help picking a system or looking at implementation? Call us today and we can help.

Other resources

Running Magento 2 in Windows with XAMPP

2019-03-22T00:00:00+00:00

Photo by Nicole De Khors · Burst, Some Rights Reserved

Magento is an open source ecommerce platform, written in PHP and relying on MySQL/MariaDB for persistence. According to BuiltWith, Magento is the third most used platform in ecommerce websites. It began its life in 2008 with its first general release, and a major update (Magento 2) was released in 2015.

And now, more than three years after, Magento 1 is slowly dying: There won’t be any more quality fixes or security updates from June 2020, and there won’t be extended support for fixes or new payment methods. So the obvious choice will be Magento 2 from now on.

But is it fully tested yet? Is it stable enough? If we already have a website running with Magento 1, what should we do? Migrating to Magento 2 is not just hitting an “Update” button: Themes are incompatible, most extensions won’t work, and of course, there’s a big set of changes to get familiar with.

So a good approach might be to get a clean Magento 2 version deployed locally, to look what we need to do to get our website updated and running, test the backend, find where the configuration sections are located, and so on. And many business users, and even some developers like myself, have Microsoft Windows installed on our computers.

Environment setup

The environment I used for this testing installation was Windows 10 Professional. As a first step, we’ll need to make sure that localhost is published in our local hosts file:

Navigate to the folder %SystemRoot%\system32\drivers\etc
Backup the existing hosts file
Open a text editor with administrator rights
Open the hosts file
Make sure the first line after the commented (#) lines is 127.0.0.1 localhost and the second is ::1 localhost
Open a cmd window with administrator rights and run the command ipconfig /flushdns

Now we’re ready to install the environment needed to run Magento. I recommend using XAMPP, a free Apache distribution for Windows that includes MariaDB, PHP, and Perl in a single package. Magento 2 currently runs with PHP 7.2 and it will not work with newer versions.

Install XAMPP 7.2 with default settings: apachefriends.org/xampp-files/7.2.15/xampp-win32-7.2.15-0-VC15-installer.exe
Download Magento 2. You will need to register on the website first: magento.com/tech-resources/download
Create a new “magento” subfolder (or whatever name you prefer) inside the htdocs folder in the XAMPP installation (usually C:\xampp) and uncompress the Magento 2 archive there.
Start the XAMPP Control Panel from the Windows start menu. In the “Apache” section, click the “Config” button and, on the menu that appears, select “PHP (php.ini)”. Remove the semicolon before the extension=intl, extension=soap, and extension=xsl texts to enable the intl, soap and xsl extensions.

Screenshot of the XAMPP Control Panel with the PHP config menu displayed.

MySQL and Magento setup

We have all the files in place and the environment ready to start configuring the database and install Magento 2.

Start the Apache and MySQL services from the XAMPP Control Panel. Wait for the green status texts to appear.
Create a “magento” (or whatever name you prefer) database in MySQL from phpMyAdmin, installed already on XAMPP: localhost/phpmyadmin
Run the Magento 2 setup from localhost/magento (replace the “magento” part of the URL with whatever name you have chosen to host Magento). If the setup program requires to do any additional configuration change, do it as instructed. Do a screenshot or save the final page contents for later use.

Example of the page that will be displayed when the Magento 2 installation finishes.

Fixing known issues

When we finish the installation process, we will have a Magento 2 instance running on our host. But we’re not ready yet! There are a couple known bugs with Magento 2 and XAMPP at the moment I’m writing this post:

The Magento admin page may not work (it shows a blank page): Fix this issue by updating the “isPathInDirectories” function inside the Validator.php file as instructed in this article.
We might not be able to upload images (like a custom logo or product pictures): Fix this issue by updating the design_config_form.xml file as shown here.

After we finish making these changes, we will need to restart the Apache service from the XAMPP control panel. And that’s it! We should be ready to open the Magento front page, and login into the backend.

An empty home page with the default theme enabled in Magento 2.

This is how the Magento 2 back-end dashboard looks like once we login.

Setting up the store: A roadmap

The purpose of this article is to get Magento 2 up and running on Windows computer, and that’s what I hope we’ve achieved so far. But just to point in a direction on what to do next, below is my usual roadmap to set up the store, add a few products and publish the catalog on the home page.

Change the default store name and logo from the section Content > Design > Configuration and choose “Edit” in the “Default store view”.
Set up the default store configuration from the section Stores > Configuration.
Create the product categories from the section Catalog > Categories. Set up a category name and its dependency from another category, or from the default master category.
Create/edit the product attributes from the section Stores > Attributes (check the option “visible in storefront” to show the products in the product page). For example, custom attributes for book products would be Author, Publisher…
Add the attributes to the default attribute set from the section Stores > Attribute. This is required for the attributes to show up when adding a new product by default.
Create a set of products from the section Catalog > Products. Set the custom variations for each product from the “Customizable options” section. Set up a short and long description, a custom SKU for each customizable option, and a tax mode.
Add a widget to the homepage to show the product catalog from the section Content > Homepage > Edit > Show/Hide Editor > Add widget > Products list. Here we can also add any content we like, including HTML tags, images, and third-party content.

Conclusion

It’s possible—and pretty straightforward—to run a Magento 2 instance in Windows with XAMPP. But this is just a kick-off, a simple overview: there’s a lot more to do if we want to get a full ecommerce website that is ready to scale up and support enterprise-level traffic, like caching optimization, load balancing, and advanced server-side monitoring.

At End Point, we have professionals with a strong background in deploying powerful, reliable, fully responsive, fast, and SEO-optimized ecommerce websites. We have experience in migrating Magento to newer versions, and even creating full Magento 2 websites from scratch. Drop us a line if you want to hear more.

Currency exchange rates with exchangeratesapi.io

2018-07-14T00:00:00+00:00

Several of our clients run ecommerce sites, built on custom software, that allow customers to pay in their choice of a few different currencies.

Some have set up separate merchant bank accounts for each currency and use separate payment gateway accounts to accept payments natively in each currency. But more commonly they use a payment gateway that allows them to accept payment in several currencies, but receive funds converted into their specified native currency in their merchant bank account.

In either case, it is common to store prices for products, shipping, etc. in one base currency (say, USD for companies based in the U.S.) and dynamically convert prices for customers. Non-native prices may need to be marked up to cover the cost of conversion into the native currency, depending on the terms of the agreement with the payment gateway or bank.

Because currency exchange rates change often, and because payment gateways generally do not offer a way to retrieve the exchange rates in advance, we need our own source for ongoing retrieval and storage of our exchange rates (also known as forex rates).

For a while we were very pleased with Fixer.io, which was a free service that collected exchange rates from the European Central Bank (ECB) and provided current or historical rates via a simple JSON API. We were sad to find that in March 2018 they deprecated that API and in June 2018 they discontinued it entirely, as described to their users. Fixer.io has transitioned to a paid service and they appear to have improved their operation to retrieve exchange rate data from at least a dozen more sources than the ECB, and to store far more frequent rate updates. Those are nice features, but not something our clients need.

Fixer.io still offers a free plan that allows 1000 API calls per month but in that plan the exchange rates are all based on the Euro. You need to sign up for at least the $10/month plan to retrieve exchange rates from the other currencies as base. As our customers needed exchange rates based on USD and CAD, the free plan wouldn’t work for us. They offer a limited-time Legacy Plan which would work, but that would just be “kicking the can down the road” until that plan too is discontinued. Their lowest paid plan is inexpensive, but with one of our clients retrieving exchange rates just once per week for only 4 currencies, it felt like overkill to track another paid service and API key, deal with renewals and updated credit card payment details, etc.

We quickly found another service called Exchange Rates API, run by Madis Väin, which is free to use without any account setup or API key needed. It is also based on the published ECB exchange rates, and uses the same API that Fixer.io did. The server side is open source written in Python using the Sanic web server library (similar to Flask, but focused on speed and async request handlers).

The ExchangeRatesAPI.io service runs on Heroku and the open source code is easy to deploy to your own Heroku instance if you want to run your own private service.

Thanks to Madis Väin for providing it, and to Fixer.io for the good service in the past!

Ecommerce Shakeups: Magento Acquisition and Etsy Rate Increases

2018-06-19T00:00:00+00:00

If you’ve been paying any attention to much in the ecommerce world, there have been a couple shakeups and transitions that could affect how you look at your ecommerce options these days.

Adobe to Acquire Magento

A few weeks ago, it was announced Adobe would acquire Magento in a large acquisition. We’ve seen Magento clients come and go. It used to be the case that the Magento Community version was free and open source, but lacking in features, and the Magento Enterprise version was not free and came with many more features but was closed source.

But, times change, and admittedly I haven’t looked into the current Magento offerings until writing this post. The two current options for Magento are Magento Commerce Starter and Magento Commerce Pro, more details here. These plans are not for small potatoes, starting at $2k/mo. I can see how the cost of this is worth it in lieu of paying a full time developer, but this is not a good fit for small businesses just getting started.

There at not many public details on the acquisition, other than bringing Magento to Adobe’s range of “physical and digital goods across a range of industries, including consumer packaged goods, retail, wholesale, manufacturing, and the public sector”. Only time will tell.

Etsy Hikes Rates

I am personally connected to the craft industry by way of my own hobby, so I’ve heard rumblings of the changes going on within Etsy with a new CEO throughout the last year. They will be shutting down Etsy wholesale as of July 31st, 2018, closing Etsy Studio & Manufacturing later this year, and last week, they announced increasing transaction fees from 3.5% to 5% which will now also apply to shipping charges. With that money, they will be offering improved tools and marketing efforts. You can read the official announcement here and more Q&A from Etsy here.

There are so many overwhelming options when it comes to determining what the best ecommerce solution is for any size of ecommerce business, and whether or not now is the right time to move away from Etsy. There is no one size fits all approach, and the best solution is very dependent on the company size and sales, in-house personnel and their skillset, structural organization, and so much more.

There are many competing SaaS options like Shopify, Big Commerce, Big Cartel, Squarespace. We’ve helped set up these software as a solution environments for many clients and they can be a great fit for business owners interested in offloading support and maintenance. In addition to SaaS options, WooCommerce in WordPress is the most popular open-source [free] solution, although many plugins and themes for it are not free. There are plenty of other open source ecommerce options out there, running on a web framework/language (Ruby on Rails, Django, MVC in PHP, etc.) of your choosing.

Conclusion

Like I mentioned above, finding the right solution is very circumstantial. I tend to suggest starting with a low-investment starting point for ecommerce, in whatever shape or form that takes for you, and then incrementally moving up if that’s what you need.

While Etsy might offer a nice low-investment starting point, more exposure and marketing tools, you ultimately aren’t building your own brand on your own domain. I have seen a handful of people in the craft industry keep their Etsy shop open for a specific audience but grow things on their own domain running on another SaaS platform.

On the flip side, many of End Point clients have businesses that are further along and the more enterprisey versions or custom software development solutions make great sense for them, with or without in-house development staff.

If you’re interested in finding out more about setting up a SaaS shop, moving away from Etsy, or understanding your options with Magento, contact us to find out how we can support your business goals.

Instant TLS Upgrades Through Proxy Magic!

2018-06-14T00:00:00+00:00

TLS shutdowns are real

The payment gateways have been warning for years about the impending and required TLS updates. Authorize.net and PayPal—to name a few—have stopped accepting transaction requests from servers using TLS 1.0. Despite the many warnings about this (and many delays in the final enforcement date), some projects are affected by this and payments are coming to a stop, customers cannot checkout, and e-commerce is at a standstill.

Ideally, getting to security compliance would include a larger migration to update your underlying operating system and your application. But a migration and software update can be an expensive project and in some cases, the business can’t wait weeks while this is done.

End Point has worked with several clients recently to try to remedy the situation by using a reverse proxy to fix this and we’ve had good success on getting payments flowing again.

What is a proxy?

A proxy is a mid-point, essentially a digital middleman, moving your data from one place to another. In two recent client instances, we ended up using nginx (the stack’s webserver) as the reverse proxy, basically running a separate server for just shuttling requests to/from the payment gateway. Since we want to be able to run the gateway in both live and test modes, we use two separate server definitions in our nginx include, one for each.

Since the proxy is talking to the gateway in TLS 1.2 the payment gateway is happy. Since the application can talk http to the proxy running on the same machine, your application is happy. Since payments are now flowing, the business is happy.

Why use a proxy?

While we always impress on clients the importance of staying up-to-date with their entire stack (operating system, language, application frameworks), this is not always practical for some sites, whether for cost reasons or some technical limitations which keep them on a specific library or framework version. In our case, these clients had been migrated to CentOS 7 already (which supports TLS 1.2), but the versions of Ruby and Ruby on Rails they were on were too old to be able to use the TLS 1.2 libraries built-in.

This can then be a fast way to get payments flowing again, ideally the first step on updating the site to work with a modern stack. This can also minimize development costs compared to doing a full migration or complete stack upgrade.

Steps

Run on an operating system version that supports TLS 1.2 natively. In practice for us, this is CentOS 7, but modern Debian, Ubuntu, and other Linux distributions would work.
Locate the existing payment gateway URLs for live and test modes. For Authorize.net, this differs depending on if you are connecting to their legacy systems or their modern systems.
Set up and configure the proxy. We used nginx for this; a later section covers the sample configs with explanations. We created a config file that we can just drop in an /etc/nginx/sites/ directory to be able to quickly set up and deploy the reverse proxies.
Adjust the configuration of the software to point to alternate payment gateway URLs. If you are using Rails’ ActiveMerchant, this can be accomplished via an application-level configuration override. We provide an example of the overriding of the live/test mode URLs for a Rails application later.

nginx sample config

# apitest.authorize.net

server {
    listen 127.0.0.1:1337 default_server;

    resolver 8.8.8.8;

    access_log /var/log/nginx/sites/authnet-proxies/access_log;
    error_log /var/log/nginx/sites/authnet-proxies/error_log warn;

    location / {
        proxy_pass_header Authorization;
        proxy_pass https://apitest.authorize.net$request_uri;
        proxy_set_header Host apitest.authorize.net;
        proxy_redirect off;
    }
}

# api.authorize.net

server {
    listen 127.0.0.1:1338 default_server;

    resolver 8.8.8.8;

    access_log /var/log/nginx/sites/authnet-proxies/access_log;
    error_log /var/log/nginx/sites/authnet-proxies/error_log warn;

    location / {
        proxy_pass_header Authorization;
        proxy_pass https://api.authorize.net$request_uri;
        proxy_set_header Host api.authorize.net;
        proxy_redirect off;
    }
}

In this file, we are defining a separate server block for each service (test mode and production), choosing an arbitrarily defined TCP port. Because nginx is speaking TLS 1.2 to the upstream gateway and we are speaking plain HTTP only to localhost and not storing any information regarding the request, we are able to fulfill the PCI DSS requirements.

A few notes about this:

We needed the resolver line for this to work given our configuration/setup because we are referring to the upstream servers by domain name instead of IP addresses; we just used the easily-memorable Google public DNS resolver servers for this purpose.
We need the Authorization header passed through the proxy, as this is what contains the site credentials when making a request from ActiveMerchant.
We need the Host header defined explicitly in the server block, as we want to override the localhost value that will be sent by the application due to application configuration. Authorize.net was (understandably) very picky about this being provided and correct.
The port numbers here are arbitrary and just need to match what we configure the application to connect to; one for the test server and one for production.
This setup will work for multiple development environments running on the same server as long as they are configured to point to the correct test/live server. There is nothing inherently insecure about doing this, as no authorization is shared, it just bounces the connection.

Rails sample application config

A configuration file for the Authorize.net CIM gateway, for clients using ActiveMerchant as the base for payment gateway integration:

require File.expand_path('../boot', __FILE__)
require 'rails/all'

module MyApp
  class Application < Rails::Application
    ActiveMerchant::Billing::AuthorizeNetCimGateway.test_url = 'http://localhost:1337/xml/v1/request.api'
    ActiveMerchant::Billing::AuthorizeNetCimGateway.live_url = 'http://localhost:1338/xml/v1/request.api'
  end
end

And another one for the legacy Authorize.net gateway:

require File.expand_path('../boot', __FILE__)
require 'rails/all'

module MyApp
  class Application < Rails::Application
    ActiveMerchant::Billing::AuthorizeNetGateway.test_url = 'http://localhost:1337/gateway/transaction.dll'
    ActiveMerchant::Billing::AuthorizeNetGateway.live_url = 'http://localhost:1338/gateway/transaction.dll'
  end
end

Ensure that you override the URLs depending on the gateway setup that your merchant account is set up for. Also make sure that your localhost URLs are using the ports corresponding to the server blocks set up in nginx to make sure these are proxying to the correct server.

While this example is using Authorize.net, you could use a similar setup for any payment gateway which allows you to set the URLs.

Summary

Hopefully this gives you some ideas about how you can use reverse proxies to upgrade the outgoing connection strength. If you need assistance getting something like this set up, feel free to contact us for help.

(Co-authored by Elizabeth Garrett Christensen.)

Expert Help with Your SaaS System

2018-04-23T00:00:00+00:00

Are you thinking about starting a new website and using BigCommerce, Shopify, or WooCommerce? The software-as-a-service offerings on the market today can help you get a great-looking, low-cost ecommerce website up and running quickly, but you may need more help than you first expect.

In order to get the most out of your site, ecommerce consultants like us at End Point can guide you through setup, customize your site to fit your brand, manage all of your technical requirements, and help drive traffic to your site. This post is an overview of services we offer to clients looking for a SaaS solution.

Select the Right Vendor

Working with an expert consultant can help you make the right choices from the start. Sometimes knowing the level of customization that your project requires can be a real challenge. End Point has experience with everything from out-of-the-box SaaS platforms to large-scale, custom software developments—we take time to understand your requirements and guide you to the perfect solution for your business.

Custom Design

Most SaaS offerings include ready-to-use, beautiful design templates, but you’ll often find that they require some tweaking. We can customize your design so that it fits perfectly with the look and feel of your brand, without the time and expense of going through the design process from scratch.

Working with an ecommerce consultant that has experience with user behavior, site navigation, and business workflows can help you develop the best way to organize your pages and products. With improved navigation, we can ensure that your users are finding what they’re looking for and getting where they’re going quickly and seamlessly.

Customizing Your Store

Customizing your store to work with your specific needs, like shipping integrations, 3rd party apps, and APIs can be a challenge. End Point can help you research the solutions already in place, or build custom solutions for your site.

Email Setup

End Point can help you set up your email on your desktop or in the cloud, and can help you configure and maintain all of your in-house email needs.

DNS and Domain Names

End Point has DevOps experts who can make sure everything with your domain name and DNS changes is handled quickly and correctly during the setup or migration of your site from one provider to another.

Search Engine Optimization (SEO)

A solid search engine optimization strategy is critical to the success of your website, and therefore critical to the success of your business. A high Google ranking means more page views—and more conversions. At End Point, we design and build with SEO in mind from the start to help you get the most value from your online presence.

Payments and Merchants

End Point has experience with many major merchant vendors. We can help you find the right merchant, be it PayPal, Stripe, Authorize.net, Braintree, etc. We can make sure that payments are set up, tested, and integrated into your business cash flow. We also have experience with PCI compliance and can help you step through an evaluation or mitigation process and get your system in tip-top shape.

Project Management

Are you trying to wrangle a team of people? Your old vendor and your new one? Do you need help in managing the project? Our project managers are here to help you meet your business goals and get to the finish line on time and within budget.

System Migrations

Working with an expert consultant can really help when you are moving from one system to another. We have customizable data export and import scripts and many automated tools to move your content to your new platform and can save you hours of moving products and pages by hand.

Summary

Working with a consultant agency can really give your SaaS project the professional edge you’ll need to compete in today’s ecommerce market. We offer consulting packages to fit your budget and the depth of services that you need. Talk to us today about how we could help get your project off the ground.

(Jon Allen co-authored this article.)

Vue in Ecommerce: Routing and Persistence

2018-03-01T00:00:00+00:00

I recently wrote about Vue in Ecommerce and pointed to a handful of references to get started. Today, I’ll talk about using vue-router in a small ecommerce application, combined with vuex-persist for state storage.

I forked this Vue Shop on GitHub from Matheus Azzi. It was a great starting point for to see how basic component organization and state management might look in a Vue ecommerce application, but it is a single page ecommerce app with no separate page for a product detail, checkout, or static pages, so here I go into some details on routing and persistence in a Vue ecommerce application.

Vue Router

In looking through the documentation, I don’t see a great elevator pitch on what it is that Vue Router does. If you are new to routing, it’s a tool to map the URL request to the Vue component. Since I’m coming from the Rails perspective, I’m quite familiar with the Ruby on Rails routing from URL pattern matching, constraints, resources to Ruby on Rails controllers and actions. Vue routing via vue-router has some similar elements.

When you create a basic Vue application via vue-cli, you are given the option to include vue-router:

vue init webpack myapp

? Project name myapp
? Project description A Vue.js project
? Author Steph <steph@endpoint.com>
? Vue build standalone
? Install vue-router? (Y/n)

If you select Yes here, the main differences you’ll see are that an application with vue-router installed will call <router-view/> to render the view for the current router, instead of a <HelloWorld/> component, and that a vue-router app will include src/router/index.js with basic routing configuration to your <HelloWorld/> component.

Without Routing

// App.vue without vue-router
<template>
  <div id="app">
    <img src="./assets/logo.png">
    <HelloWorld/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld'

export default {
  name: 'App',
  components: {
    HelloWorld
  }
}
</script>

With Routing

// App.vue with vue-router
<template>
  <div id="app">
    <img src="./assets/logo.png">
    <router-view/>
  </div>
</template>

<script>
export default {
  name: 'App'
}
</script>


// src/router/index.js
import Vue from 'vue'
import Router from 'vue-router'
import HelloWorld from '@/components/HelloWorld'

Vue.use(Router)

export default new Router({
  routes: [
    {
      path: '/',
      name: 'HelloWorld',
      component: HelloWorld
    }
  ]
})

Moving on, building out an ecommerce app with some basic page set up, not including user accounts, might look like the setup below, which includes basic components and routes for the Home, Cart, Checkout, Receipt, and About page. This simplified set-up doesn’t even include a product detail page, but one could accomplish that with a bit of URL matching via parameters.

// src/router/index.js
import Vue from 'vue'
import Router from 'vue-router'

import Home from '@/components/pages/Home'
import Receipt from '@/components/pages/Receipt'
import About from '@/components/pages/About'
import Cart from '@/components/pages/Cart'
import Checkout from '@/components/pages/Checkout'

Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    { path: '/', component: Home },
    { path: '/receipt', component: Receipt },
    { path: '/about', component: About },
    { path: '/cart', component: Cart },
    { path: '/checkout', component: Checkout }
  ]
})

History Mode

One thing you also might notice is the ‘history’ mode setting above, overriding the default hash mode. You can read about that here, but it leverages history.pushState to URL navigation. The history mode override must be combined with server configuration to ensure that non-static asset URL requests (i.e. all of our routes) hit the Vue index.html app in our Vue application, and then renders the component associated with the requested route. I’m using Apache for my Vue application, so I followed the instructions on that documentation for vue-router history mode configuration.

Using <router-link/>

One thing you also will want to use throughout your templates is <router-link/>, instead of hard-coding rigid URL paths. For example, instead of linking to the cart via <a href="/cart">Cart</a>, you’ll want to link via <router-link to="cart">Cart</router-link>. This will be resolve to the proper link upon rendering depending on your routing configuration.

Vuex PersistedState

If you are still reading, you’ve now seen the basic configuration for vue-router in an ecommerce application running on Vue. The ecommerce application I forked uses vuex, a state management pattern and library to store the state of our application. What you’ll notice with a shopping cart application, though, is that you need to persist the state of your cart for sessions. Without further setup, every page refresh on your application will result in losing the state of the cart.

To address this behavior, there are a few options to persist your state in Vue. I chose vuex-persist, which stores the state (for all modules or specific modules) in localStorage. After installing vuex-persist, I modified the following to include the shoppingCart module in my stored state:

// src/store/index.js
import Vue from 'vue'
import Vuex from 'vuex'
import VuexPersistence from 'vuex-persist'
// import other stuff

Vue.use(Vuex)
const vuexLocal = new VuexPersistence({
  storage: window.localStorage,
  reducer: state => ({
    shoppingCart: state.shoppingCart
  })
})

export default new Vuex.Store({
  // ...
  plugins: [vuexLocal.plugin]
})

It’s as simple as that to persist the state of your shopping cart using all the vuex-persist defaults, and there are some alternative Promise-based stores supported if you are interested.

What’s Next?

What’s next in building out your ecommerce application? From here, one might consider adding user authentication & authorization support, as well as support for retrieving and rendering products in the product list view. I hope to address those in upcoming blog posts in this series on Vue in ecommerce.

Vue and Ecommerce: An Introduction

2018-02-19T00:00:00+00:00

I speak the domain specific language of ecommerce, Ruby on Rails, JavaScript, and jQuery. Lately, I’ve been getting up to speed on Vue.js. I’ve been working on writing a small ecommerce site using Vue.js, because for me, creating an application addressing familiar paradigm in a new technology is a great way to learn.

Vue.js, initially released about 3 years ago, is a lightweight JS framework that can be adopted incrementally. In the case of my small example site, Vue.js serves the frontend shop content and connects to a decoupled backend that can be run on any platform of choice. On my path to get up to speed on Vue, I found great resources that I wanted to write about before I get into the details of my ecommerce app. Here they are:

First, I started with the Vue.js documentation. The documentation is great as a starting point to understand some of the terminology. I often don’t love the documentation that comes with technologies, but I found the Essentials section in the Vue documentation to be a great launching point.
After I worked through some of the Vue.js documentation, I did a simple search for “vue jsfiddle” and experimented with a few of those fiddles. Having come from a jQuery background (with mustache), I was familiar with how templating and logic inside a template might work, but less familiar with the vue instance and binding, so I targeted jsfiddles with this in mind.
Next, I looked for resources with Vue + ecommerce specifically. Here’s where I found some good stuff:
- Scotch.io Course on Vue + Ecommerce: This online course has a great amount of overlap with the main documentation of Vue, but some of the examples are ecommerce specific, which serves as a good introduction.
- Vue + Third Party Integration for Ecommerce: This Medium article talks about integrating third party tools used with Vue (Stripe, AWS S3, Heroku) to build an ecommerce site. While this post doesn’t go into the nitty gritty details of a Vue application, it does provide many code examples for checkout and payment integration, although noting that vue-stripe-elements is now the module of choice for Stripe integration in Vue.
- Vue API App + Magento Backend: This is a front-end open source Vue application designed to pair with a Magento backend, capitalizing on the popularity of Magento.
- Moltin: This company is providing backend microservices for ecommerce, with Vue.js support (and other technologies) to build out your store.
- Vue + Ecommerce with Vuex: Here’s another Medium article which features vuex, the state management library in Vue, essentially going through examples of state management to manage a shopping cart.
- CodePen Vue + Ecommerce Example: Here’s a standalone CodePen example of a Vue shopping cart. While I find this a little hard to parse because there’s a significant amount of code in the example, you can download and experiment with it.
- Stripe Integration Example: Here’s a GitHub repo that demonstrates Stripe integration in serverless Vue shop.
- Basic Vue Shop on GitHub: Why reinvent the wheel when someone has already built out product listing and cart functionality? After reviewing all the examples above, this was my choice for a starting point in building out a Vue shop, but it is a basic starter point, without the use of vue-router.

Vue Libraries / Dependencies

You might have noticed I mentioned a few Vue libraries and tools. Here are additional resources for getting up to speed on those dependencies:

Installing Node.js and npm, if you aren’t already familiar with it. Here is a great comparison if you are coming from the Rails space.
Already mentioned, vuex state management in Vue.
vue-router. In an ecommerce site, you would possibly have routing for the index, product detail, cart, checkout, user account, order detail pages.
vue-cli: simple command line interface for scaffolding Vue projects. Think “rails generate …” for Vue.
vue-resource, or a comparable module (vue-axios) for making API and AJAX requests.

Incremental Adoption

While I am writing a Vue ecommerce shop based on the shop-vue GitHub repo mentioned above, in the ecommerce space, we commonly take on incremental ecommerce updates rather than “The Big Rewrite”, as noted in Greg’s article. Components that could be introduced incrementally into existing ecommerce applications might include:

Dynamic marketing elements on homepage or product listing page, e.g. promo tools, “Customers Also Looked at”, “Products Recently Viewed”
Cart + Checkout process (standalone component)
Admin elements for data management and processing
User account section

Sunsetting Piggybak, A Ruby on Rails Ecommerce Gem

2018-02-14T00:00:00+00:00

Hi there! I’m Steph, the original creator and not-very-good maintainer of Piggybak, a modular ecommerce platform written in Ruby on Rails. With the help of End Point, I created Piggybak after building a custom Ruby on Rails ecommerce application for one of our clients here at End Point.

My goal with Piggybak was to create a lightweight, modular ecommerce platform in the form of a Ruby on Rails gem that could be combined with other Ruby on Rails gems for quick setup. Over the years, End Point has had much success working in Interchange, an ecommerce framework written in Perl. The web stack has evolved greatly over the years, as has the capacity for modularity and the ability to decouple front-end and back-end architecture.

Fast forward about 4 years after Piggybak was released, and we’ve decided to retire it. Not only did I leave the maintenance up to End Point after I left to work as an in-house software engineer for the last couple of years, but I was also in a position to evaluate using Piggybak as the base for a custom solution.

While I think there are some great Ruby on Rails gems to help support your ecommerce application (see below), one of the main things I realized was that the modularity in Piggybak often doesn’t suit the needs for the target audience of custom Ruby on Rails ecommerce platforms.

These days, here’s my oversimplified categorization of those looking for ecommerce solutions, divided into two audiences:

Audience #1: Boilerplate Saas with Theme Customization
Those sellers where boilerplate ecommerce solutions work, with simple product and variant modeling. Shopify, Magento, BigCommerce, WooCommerce can be decent popular options for that audience, but there are so many other options out there.

Audience #2: Custom Ecommerce in Ruby on Rails
Companies going this route have custom enough needs where a small team can develop and maintain a custom solution, using Ruby on Rails efficiently that don’t require them to depend on a pre-existing data model or business rule.

Not only did Piggybak suffer from a lack of community involvement, but it also didn’t suit the needs of the two audiences listed above. Because it was complex enough written in the form of a Rails gem (engine), it required a developer with some knowledge to install and customize further. And because it defined assumptions around the product-variant data model and business rules for inventory and payment management, it wasn’t necessarily a good fit for custom ecommerce needs.

Other Ruby on Rails Gems

While I’m sad to sunset Piggybak, I still believe Rails offers great options for ecommerce needs, including these popular Ruby on Rails gems:

Rails_admin, active_admin (no longer maintained), administrate
Carrierwave: File attachment management. Has decent third party support.
Devise. User authentication marches on.
Cancancan. User authorization.
Kaminari. Pagination.
RSpec, FactoryBot, Capybara, the testing stack I am most familiar with.
ActiveShipping. Shipping for ecommerce.
ActiveMerchant. Payment gateways for ecommerce.

If you are wondering if there are any Ruby on Rails ecommerce gems still out there, you can look at Solidus, Spree, and RoR-E. End Point has a long history with Spree, and experience with the other two platforms, but again, the audience of those businesses choosing a custom path may not want to be tied to the data models and business rules adopted by these existing platforms.

End Point Featured as Global Leader in Ruby on Rails & Ecommerce Development

2017-12-21T00:00:00+00:00

As the year comes to a close and we reflect on the goals we’ve accomplished and the work that made it all possible, we are proud to announce our inclusion on the Clutch Global Leaders List, encapsulating the 475+ most highly reviewed companies from around the world. We placed as a leader on both Top Ruby on Rails Developers and Top Ecommerce Developers, being the best New York-based firm on the former and in the top three from New York on the latter.

Achieving the status of a Clutch Global Leader in not just one, but two categories speaks volumes on the effort we’ve put forth in 2017. We couldn’t have hit this milestone without skilled work from End Point staff and the great relationships we’ve nurtured with clients. Looking back on these memorable projects, here are some of the things are clients wrote on our Clutch profile:

“I’ve worked with a lot of different service providers. Results can vary across the board. End Point is very transparent about what they’re working on in terms of providing complete details. We don’t have any surprises at the end of the month as a result. They’re very dependable, delivering what they promise every time,” explained the Director of Ecommerce for a tourism marketing company.

They went on to describe our flexibility and close partnership:

“Many of their team members are instrumental in helping us keep doing everything that we need. Our business evolves and changes. They help us make sure that what we’re building is up to snuff, and scales well with our company. We’ve grown considerably since we’ve hired them.”

Another client, the owner of a B2B platform, commented on our project management expertise and what it was like to work with our team:

“I am very satisfied with End Point. They are a fantastic company to work with. Their engineers are outstanding, their communication skills are excellent, and the delivery speed is great. I have nothing but good things to say about their company.”

To learn more about our clients’ experiences and how we’ve achieved the status of a Clutch Global Leader, stay up-to-date with our Clutch profile.

Client Case Study: Vervante—Publishing, Production and Fulfillment Services

2017-08-28T00:00:00+00:00

A real-life scenario

The following is a real-life example of services we have provided for one of our clients.

Vervante Corporation provides a print on demand and order fulfillment service for thousands of customers, in their case, “Authors”. Vervante needed a way for these authors to keep track of their products. Essentially they needed an Inventory management system. So we designed a complete system from the ground up that allows Vervante’s authors many custom functions that simply are not offered in a pre-built package anywhere.

This is also a good time to mention that you should always view your web presence, in fact your business itself, as a process, not a one time “setup”. Your products will change, your customers will change, the web will change, everything will change. If you want your business to be successful, you will change.

Some Specifics

While it is beyond the scope of this case study to describe all of the programs that were developed for Vervante, it will be valuable for the reader to sample just a few of the areas to understand how diverse a single business can be. Here are a few of the functions we have built from scratch, over several years to continue to provide Vervante, their authors, and even their vendors with efficient processes to achieve their daily business needs.

Requirements

Author Requirement—First, in some cases, the best approach to a problem is to use someone else’s solution! Vervante’s authors have large data files that are converted to a product, and then shipped on demand as the orders come in. So we initially provided a custom file transfer process so that customers could directly upload their files to a server we set up for Vervante. Soon Vervante’s rapid growth outpaced the efficacy of this system, so we investigated and determined the most efficient and cost-effective approach was to incorporate a 3rd party service. So we recommended a well known file transfer service and wrote a program to communicate with the file transfer service API. Now a client can easily describe and upload large files to Vervante.

View File Save Process

Storage Requirement—The remote storage of these large files caused Vervante a dramatic inefficiency as relates to access times, as they worked daily on these files to format, organize, and create product masters. So we needed to provide Vervante with a local server to act as a file server that was on their local network (LAN), where it could be rapidly accessed and manipulated. This was a challenge, as Vervante did not have IT personnel on site. So we purchased an appropriate server, set up everything in our offices, and shipped the complete server to them! They plugged the server into their local network, and with a long phone call, we had the server up and running and remotely managed.
Author Requirement—On the website, the authors first wanted to see what they had in inventory. Some customers provided Vervante with some product components that needed to be included with a complete product, while others relied on Vervante to build all components of their products. They also requested a way to set minimum inventory stock requirements.

So we built an interface that would allow authors to:

(a) See their current stock levels for all products,

(b) View outstanding orders for these items,

For example a finished product may consist of a book, a CD, and a DVD. A customer may supply the CD and require Vervante to produce the book and the DVD “on demand” for the product. We created a system that tracked all items at a “base” item level, and then allowed Vervante to “build” products with as many of these “base” items as necessary, to create the final product. The base items could be combined to create an item, and two or more items could be combined to produce yet another item. It is a recursive item inventory system, built from scratch specifically for Vervante.

Vervante Vendor (fulfillment warehouse) Requirement—Additionally, the fulfillment warehouse that receives, stores, builds and ships end user products, needed access to this system. They had several needs including:
- Retrieving pending orders for shipment
- Creating packing / pick slips for the orders
- Create shipping labels for orders
- Manage returns
- Input customer supplied inventory
- Input fulfillment created inventory

In our administrative user interface for the fulfillment house, we developed a series of customer specific processes to address the above needs. Here is a high level example of how a few of the items on the list above are achieved:

- The fulfillment house logs into the user admin first thing in the morning, and prints the outstanding orders.
- The “orders” are formatted similar to a packing slip, and each slip has all line items of the order, and a bar code imprinted on the slip.
- This document is used as a “pick” slip, and is placed in a “pick” basket. The user then goes through the warehouse, gathers the appropriate items, and when complete the order is placed on a feed belt to the shipper location.
- When the basket lands in front of the shipper, that person checks the contents of the basket against the slip, and then uses a bar code scanner to scan the order. That scan triggers a query into our system that returns all applicable shipping data into an Endicia or UPS system. 
- A shipping label is created, and the shipping cost and tracking information is returned to the our system.
- Additionally the inventory is decremented accordingly when the order receives a shipping label and tracking number.

Requirements: administrative / accounting—Vervante also needed an administrative / accounting arm, designed to control all of the accounting functions such as:
- Recording customers’ fulfillment charges
- Recording customers’ sales (Vervante sells product for the customers as well as fulfilling outside orders)
- Determining fulfillment vendor fees and payments
- Tracking shipping costs
- Monthly billing of all customers
- Monthly payments for all customers.
- Interface with in-house accounting systems and keeping systems in sync
- Tracking and posting outside order transactions

The above described processes are just a few of the processes that we developed from scratch, and matched to Vervante’s needs. It is also a tiny portion of their system.

Last, but not least

Oh, and one other interesting fact: When Vervante first came to us several years ago, they had fewer than 20 customers. Today, they provide order fulfillment and print on demand services for nearly 4000 customers. So when we say to plan ahead for growth, we have experience in that area.

Custom eCommerce Development

2017-08-28T00:00:00+00:00

“Custom eCommerce” means different things to different people and organizations. For some eCommerce shopping cart sites that pump out literally hundreds of websites a year, it may mean you get to choose from a dizzying array of “templates” that can set your website apart from others.

For others, it may be a slightly more involved arrangement where you can “create categories” to group display of your products on your website … after you have entered your products into a prearranged database schema.

There are many levels of “custom” out there. Generally speaking, the closer you get to true “custom”, the more accurate the term “development” becomes.

It is very important for your business that you decide what fits your needs, and that you match your needs to a platform or company that can provide appropriate services. As you can imagine, this will depend entirely on your business.

Example scenarios

For example, a small one- or two-person business that does fulfillment of online orders may be well suited for a pre-built approach, where you pay a monthly fee to simply log into an admin, add your products, and some content, and the company does the rest. It handles all of the “details.”

A slightly larger company that has maybe 5–10 employees, and possibly a staff member with some understanding of websites, may choose to purchase a package that requires more customization and company related input, and perhaps even design or choice of templates.

From this level up, decisions become far more important and complex. For example, even though the previously described company may be perfectly suited with the choice described, if sales are expected to increase dramatically in the near future, or if the company is in a niche market where custom accounting or regulations require specific handling of records, a more advanced approach may be warranted.

What we do

The purpose of this post is not to give you guidelines as to what sort of website service you should buy, or consultancy you should hire for your company. Rather it is to point out some of the types of things that we at End Point do for companies that need a higher level of custom eCommerce development. In fact, the development we do is not limited to eCommerce.

We offer a full range of business consultancy and IT development services. We can guide you through many areas of your business development. True, we primarily provide services to companies that sell things on the web. But we also provide support for inventory management systems in your warehouses, accounts receivable / payable integration with your websites, management of your POS (point of sale) machines, strategic pricing for seasonal products with expiry dates, and the list goes on.

Real-life scenarios

The following is a real-life example of services we have provided for one client.

Case Study: Vervante

Consultant vs Service

Hopefully, the real life scenarios will help serve as an example as to how complex business needs can be, and how using an out of the box “eCommerce” website, will not work in every circumstance. When you find a good business consultant, you will know it. A consultant will not try to make your business fit into their template, they will listen to you and then assemble and tailor products to fit your business.

Regardless of the state of maturity of your business, very seldom will a single “system” or “website” cover all of your business needs. It will more likely be a collection of systems. Which systems and how they work together is likely what will determine success or failure. The more mature your business, the broader the scope of systems required to support the growing requirements of your business.

So whether you are a sole proprietor getting started with your business, or you are a CTO tasked with organizing and optimizing the many systems in your organization, understanding what type of service or partner you need, is the first step. In the future I will spotlight a few other examples of how we have assisted businesses in growing and improving how they do business.

Zero Pricing in Interchange using CommonAdjust

2017-06-26T00:00:00+00:00

Product pricing can be quite complex. A typical Interchange catalog will have at least one table in the ProductFiles directive (often products plus either options or variants) and those tables will often have one or more pricing fields (usually price and sales_price). But usually a single, static price isn’t sufficient for more complex needs, such as accessory adjustments, quantity pricing, product grouping–not to mention promotions, sales, or other conditional features that may change a product’s price for a given situation, dependent on the user’s account or session.

Typically to handle these variety of pricing possibilities, a catalog developer will implement a CommonAdjust algorithm. CommonAdjust can accommodate all the above pricing adjustments and more, and is a powerful tool (yet can become quite arcane when reaching deeper complexity). CommonAdjust is enabled by setting the PriceField directive to a non-existent field value in the tables specified in ProductFiles.

To give an adequate introduction and treatise on CommonAdjust would be at a minimum its own post, and likely a series. There are many elements that make up a CommonAdjust string, and subtle operator nuances that instruct it to operate in differing patterns. It is even possible for elements themselves to return new CommonAdjust atoms (a feature we will be leveraging in this discussion). So I will assume for this writing that the reader is familiar generally with CommonAdjust and we will implement a very simple example to demonstrate henceforth.

To start, let’s create a CommonAdjust string that simply replaces the typical PriceField setting, and we’ll allow it to accommodate a static sales price:

ProductFiles products
PriceField 0
CommonAdjust :sale_price ;:price

The above, in words, indicates that our products live in the products table, and we want CommonAdjust to handle our pricing by setting PriceField to a non-existent field (0 is a safe bet not to be a valid field in the products table). Our CommonAdjust string is comprised of two atoms, both of which are settors of type database lookup. In the products table, we have 2 fields: sale_price and price. If sale_price is “set” (meaning a non-zero numeric value or another CommonAdjust atom) it will be used as it comes first in the list. The semicolon indicates to Interchange “if a previous atom set a price by this point, we’re done with this iteration” and, thus, the price field will be ignored. Otherwise, the next atom is checked (the price field), and as long as the price field is set, it will be used instead.

A few comments here:

The bare colon indicates that the field is not restricted to a particular table. Typically, to specify the field, you would have a value like “products:price” or “variants:price”. But part of the power of ProductFiles holding products in different tables is you can pick up a sku from any of them. And at that point, you don’t know whether you’re looking at a sku from products, variants, or as many additional tables as you’d like to grab products from. But if all of them have a price and sales_price field, then you can pick up the pricing from any of them by leaving the table off. You can think of “:price” as “*:price” where asterisk is “table this sku came from”.
The only indicator that CommonAdjust recognizes as a terminal value is a non-zero numeric value. The proposed price is coerced to numeric, added on to the accumulated price effects of the rest of the CommonAdjust string (if applicable), and the final value is tested for truth. If it is false (empty, undef, or 0) then the process repeats.
What happens if none of the atoms produce a non-zero numeric value? If Interchange reaches the end of the original CommonAdjust string without hitting a set atom, it will relent and return a zero cost.

At this point, we finally introduce our situation, and one that is not at all uncommon. What if I want a zero price? Let’s say I have a promotion for buy one product, get this other product for free. Typically, a developer would be able to expect to override the prices from the database optionally by leveraging the “mv_price” parameter in the cart. So, let’s adjust our CommonAdjust to accommodate that:

CommonAdjust $ ;:sale_price ;:price

The $ settor in the first atom means “look in the line-item hash for the mv_price parameter and use that, if it’s set”. But as we’ve discussed above, we “set” an atom by making it a non-zero numeric value or another CommonAdjust atom. So if we set mv_price to 0, we’ve gained nothing. CommonAdjust will move on to the next atom (sale_price database settor) and pick up that product’s pricing from the database. And even if we set that product’s sale_price and price fields to 0, it means everyone purchasing that item would get it for free (not just our promotion that allows the item to be free with the specific purchase of another item).

In the specific case of using the $ settor in CommonAdjust, we can set mv_price to the keyword “free”, and that will allow us to price the item for 0. But this restricts us to only be able to use $ and mv_price to have a free item. What if the price comes from a complex calculation, out of a usertag settor? Or out of a calc block settor? The special “free” keyword doesn’t work there.

Fortunately, there is a rarely used CommonAdjust settor that will allow for a 0 price item in a general solution. As I mentioned above, CommonAdjust calculations can themselves return other CommonAdjust atoms, which will then be operated on in a subsequent iteration. This frees us from just the special handling that works on $ and mv_price as such an atom can be returned from any of the CommonAdjust atoms and work.

The settor of interest is >>, and according to what documentation there is on it, it was never even intended to be used as a pricing settor! Rather, it was to be a way of redirecting to additional modes for shipping or tax calculations, which can also leverage CommonAdjust for their particular purposes. However, the key to its usefulness here is thus: it does not perform any test on the value tied to it. It is set, untested, into the final result of this call to the chain_cost() routine and returned. And with no test, the fact that it’s Perly false as numeric 0 is irrelevant.

So building on our current CommonAdjust, let’s leverage >> to allow our companion product to have a zero cost (assuming it is the 2nd line item in the cart):

[calcn]
    $Items->[1]{mv_price} = '>>0';
    return;
[/calcn]

Now what happens is, $ in the first atom picks up the value out of mv_price and, because it’s a CommonAdjust atom, is processed in a second iteration. But this CommonAdjust atom is very simple: take the value tied to >> and return it, untested.

Perhaps our pricing is more complex than we can (or would like to) support with using $. So we want to write a usertag, where we have the full power of global Perl at our disposal, but we still have circumstances where that usertag may need to return zero-cost items. Using the built-in “free” solution, we’re stuck, short of setting mv_price in the item hash within the usertag, which we may not want to do for a variety of reasons. But using >>, we have no such restriction. So let’s change CommonAdjust:

CommonAdjust $ ;[my-special-pricing] ;:sale_price ;:price

Now instead of setting mv_price in the item, let’s construct [my-special-pricing] to do some heavy lifting:

UserTag my-special-pricing Routine <<EOR
sub {
    # A bunch of conditional, complicated code, but then ...
    elsif (buy_one_get_one_test($item)) {
        # This is where we know this normally priced item is supposed to be
        # free because of our promotion. Excellent!

        return '>>0';
    }
    # remaining code we don't care about for this discussion
}
EOR

Now we haven’t slapped a zero cost onto the line item in a sticky fashion, like we do by setting mv_price. So presumably, above, if the user gets sneaky and removes the “buy one” sku identified by our promotion, our equally clever buy_one_get_one_test() sniffs it out, and the 0 price is no longer in effect.

For more information on CommonAdjust, see the Custom Pricing section of ‘price’ glossary entry. And for more examples of leveraging CommonAdjust for quantity and attribute pricing adjustments, see the Examples section of the CommonAdjust document entry.

Postal code pain and fun

2017-05-10T00:00:00+00:00

We do a lot of ecommerce development at End Point. You know the usual flow as a customer: Select products, add to the shopping cart, then check out. Checkout asks questions about the buyer, payment, and delivery, at least. Some online sales are for “soft goods”, downloadable items that don’t require a delivery address. Much of online sales are still for physical goods to be delivered to an address. For that, a postal code or zip code is usually required.

No postal code?

I say usually because there are some countries that do not use postal codes at all. An ecommerce site that expects to ship products to buyers in one of those countries needs to allow for an empty postal code at checkout time. Otherwise, customers may leave thinking they aren’t welcome there. The more creative among them will make up something to put in there, such as “00000” or “99999” or “NONE”.

Someone has helpfully assembled and maintains a machine-readable (in Ruby, easily convertible to JSON or other formats) list of the countries that don’t require a postal code. You may be surprised to see on the list such countries as Hong Kong, Ireland, Panama, Saudi Arabia, and South Africa. Some countries on the list actually do have postal codes but do not require them or commonly use them.

Do you really need the customer’s address?

When selling both downloadable and shipped products, it would be nice to not bother asking the customer for an address at all. Unfortunately even when there is no shipping address because there’s nothing to ship, the billing address is still needed if payment is made by credit card through a normal credit card payment gateway—as opposed to PayPal, Amazon Pay, Venmo, Bitcoin, or other alternative payment methods.

The credit card Address Verification System (AVS) allows merchants to ask a credit card issuing bank whether the mailing address provided matches the address on file for that credit card. Normally only two parts are checked: (1) the street address numeric part, for example, “123” if “123 Main St.” was provided; (2) the zip or postal code, normally only the first 5 digits for US zip codes, and often non-US postal code AVS doesn’t work at all with non-US banks.

Before sending the address to AVS, validating the format of postal codes is simple for many countries: 5 digits in the US (allowing an optional -nnnn for ZIP+4), and 4 or 5 digits in most others countries—see the Wikipedia List of postal codes in various countries for a high-level view. Canada is slightly more complicated: 6 characters total, alternating a letter followed by a number, formally with a space in the middle, like K1A 0B1 as explained in Wikipedia’s components of a Canadian postal code.

So most countries’ postal codes can be validated in software with simple regular expressions, to catch typos such as transpositions and missing or extra characters.

UK postcodes

The most complicated postal codes I have worked with is the United Kingdom’s, because they can be from 5 to 7 characters, with an unpredictable mix of letters and numbers, normally formatted with a space in the middle. The benefit they bring is that they encode a lot of detail about the address, and it’s possible to catch transposed character errors that would be missed in a purely numeric postal code. The Wikipedia article Postcodes in the United Kingdom has the gory details.

It is common to use a regular expression to validate UK postcodes in software, and many of these regexes are to some degree wrong. Most let through many invalid postcodes, and some disallow valid codes.

We recently had a client get a customer report of a valid UK postcode being rejected during checkout on their ecommerce site. The validation code was using a regex that is widely copied in software in the wild:

[A-PR-UWYZ0-9][A-HK-Y0-9][AEHMNPRTVXY0-9]?[ABEHMNPRVWXY0-9]?[0-9][ABD-HJLN-UW-Z]{2}

(This example removes support for the odd exception GIR 0AA for simplicity’s sake.)

The customer’s valid postcode that doesn’t pass that test was W1F 0DP, in London, which the Royal Mail website confirms is valid. The problem is that the regex above doesn’t allow for F in the third position, as that was not valid at the time the regex was written.

This is one problem with being too strict in validations of this sort: The rules change over time, usually to allow things that once were not allowed. Reusable, maintained software libraries that specialize in UK postal codes can keep up, but there is always lag time between when updates are released and when they’re incorporated into production software. And copied or customized regexes will likely stay the way they are until someone runs into a problem.

The ecommerce site in question is running on the Interchange ecommerce platform, which is based on Perl, so the most natural place to look for an updated validation routine is on CPAN, the Perl network of open source library code. There we find the nice module Geo::UK::Postcode which has a more current validation routine and a nice interface. It also has a function to format a UK postcode in the canonical way, capitalized (easy) and with the space in the correct place (less easy).

It also presents us with a new decision: Should we use the basic “valid” test, or the “strict” one? This is where it gets a little trickier. The “valid” check uses a regex validation approach will still let through some invalid postcodes, because it doesn’t know what all the current valid delivery destinations are. This module has a “strict” check that uses a comprehensive list of all the “outcode” data—which as you can see if you look at that source code, is extensive.

The bulkiness of that list, and its short shelf life—the likelihood that it will become outdated and reject a future valid postcode—makes strict validation checks like this of questionable value for basic ecommerce needs. Often it is better to let a few invalid postcodes through now so that future valid ones will also be allowed.

The ecommerce site I mentioned also does in-browser validation via JavaScript before ever submitting the order to the server. Loading a huge list of valid outcodes would waste a lot of bandwidth and slow down checkout loading, especially on mobile devices. So a more lax regex check there is a good choice.

When Christmas comes

There’s no Christmas gift of a single UK postal code validation solution for all needs, but there are some fun trivia notes in the Wikipedia page covering Non-geographic postal codes:

A fictional address is used by UK Royal Mail for letters to Santa Claus:

Santa’s Grotto
Reindeerland XM4 5HQ

Previously, the postcode SAN TA1 was used.

In Finland the special postal code 99999 is for Korvatunturi, the place where Santa Claus (Joulupukki in Finnish) is said to live, although mail is delivered to the Santa Claus Village in Rovaniemi.

In Canada the amount of mail sent to Santa Claus increased every Christmas, up to the point that Canada Post decided to start an official Santa Claus letter-response program in 1983. Approximately one million letters come in to Santa Claus each Christmas, including from outside of Canada, and they are answered in the same languages in which they are written. Canada Post introduced a special address for mail to Santa Claus, complete with its own postal code:

SANTA CLAUS
NORTH POLE H0H 0H0

In Belgium bpost sends a small present to children who have written a letter to Sinterklaas. They can use the non-geographic postal code 0612, which refers to the date Sinterklaas is celebrated (6 December), although a fictional town, street and house number are also used. In Dutch, the address is:

Sinterklaas
Spanjestraat 1
0612 Hemel

This translates as “1 Spain Street, 0612 Heaven”. In French, the street is called “Paradise Street”:

Saint-Nicolas
Rue du Paradis 1
0612 Ciel

That UK postcode for Santa doesn’t validate in some of the regexes, but the simpler Finnish, Canadian, and Belgian ones do, so if you want to order something online for Santa, you may want to choose one of those countries for delivery. :)

Adventures in Vibe-Coding with Replit

Project 1: Multi-LLM code review API

The prompt

The results

Project 2: End Point Ecommerce + Hugo site

The prompt

The results (version 1)

The results (version 2)

Feature addition: cart

Bonus: a few extra notes

When I’d use Replit (and similar do-it-all AI agents)

Announcing End Point Ecommerce, Our New Open Source Project

Key features

How we got here

Who is this for?

When to DIY vs Hire for Ecommerce Development

A Practical Guide for Business Owners

When to DIY (With Confidence)

Helpful DIY Tools

Watch Out For

When to Hire a Developer or Consultancy

Project Types Worth Hiring For

Keep in mind there are additional facets to DIY

The Hybrid Approach: Best of Both Worlds

What It All Costs

Conclusion: Know Your ROI

Bonus: Quick Self-Assessment

Need help evaluating your ecommerce development path?

Interchange Compression for SessionDB

Compression Performance Comparison

Configuring Your Catalog to Use Vend::Util::Compress

References

Interchange 3rd Party Tax Support

Configuring Your Catalog to Use Vend::Tax

References

Ecommerce customer names with interesting Unicode characters

Real names with bonuses

Fake names

Not names at all!

Strange addresses

Simply odd

“Interesting” Unicode ranges

The SQL query

Our Vue Storefront “Proof of Concept” Experience

PoC of Vue Storefront/​Magento 2.3

Preparing the Environment

Indexing Elasticsearch with mage2vuestorefront

Viewing the Vue Storefront Application

Designing a New Approach for Interchange

Inspired By A Similar Approach of Vue Storefront + SAP Commerce

Interchange API Prototype Design

Common and Exceptional Issues

Conclusion

Magento 2: Creating a custom theme

Creating a new Magento 2 theme

Creating a new directory for the theme

Creating registration.php

Creating theme.xml

Activating our new theme

Adding custom content

Creating a custom view file

Adding a custom logo

Adding static files (JavaScript/​CSS/​images/​fonts)

Adding a custom layout

Shopify Admin API: Importing Products in Bulk

Application Requirements

Retrieving Card Artwork and Pricing

Working With the Shopify Admin API in Ruby

Pushing 50,000 Products to Shopify

Conclusion

Magento 2: Creating a custom module

Creating a basic Magento 2 module

Creating a new directory for the module

Creating the registration.php script

Creating the etc/module.xml information file

Installing the new module

Adding a custom route to our module

Creating a new directory for the controller

Creating the etc/routes.xml file

Creating the controller

PoC of Vue Storefront/Magento 2.3

Adding static files (JavaScript/CSS/images/fonts)

Client Case Study: Vervante—Publishing, Production and Fulfillment Services