Are we wrong to avoid JAM stack?

Opentalk
1

I asked my CTO today:

What would you say is your biggest barrier, technical or otherwise, to building more sites using the JAMstack architecture?

He replied:

Our in-app sites are not due to the following:

  • No need for SEO since they are behind a login wall.
  • Pure Vue.js SPA is more flexible than current frameworks like Gridsome (not very actively developed, has limitations like i18n for long time).

Is he right? And if so, why is Netlify constantly advocating JAMstack instead of more flexible ways to build apps? Is JAMstack just for landing pages?

2

Hi, @maxhodges!

A pure Vue.js SPA actually is a Jamstack app — there’s no requirement to use something like Gridsome for a site to take advantage of the benefits of the Jamstack.

What makes a Jamstack app a “Jamstack app” is:

1. It’s composed of static assets — there’s no server-rendering step that generates the markup (e.g an Express or PHP templating step). This means the app can be served from a CDN (or S3 bucket, etc.) and doesn’t require specialized hosting.

2. It handles dynamic content via async JavaScript — because there’s no server, any dynamic content or user interactions are handled by calling out to an API, serverless function, microservice, etc.

These are really the only hard requirements for something to be considered “Jamstack”.

Because of this, you can build pretty much any app frontend you can imagine on the Jamstack. Getting into the details about static page generation (e.g. Gridsome) vs. client rendering everything (e.g. Vue SPA) is less about the Jamstack and more about specific goals of the project.

I hope that helps!

2 Likes
3

Thanks @jlengstorf

a pure Vue.js SPA actually is a Jamstack app

But we have a node server.

Jamstack.org writes:

Any project that relies on a tight coupling between client and server is not built with the Jamstack.

Also, the M is for “Markup”, so JAMstack apps are expected to download mostly HTML, not mostly JS

A normal SPA (and our SPA) is mostly JS, and then the browser runs the JS and builds HTML

Also, our app is not prebuilt (not good for SEO, but we have a paywall) so it is not exactly a JAM stack right?.

So somehow we are still JAMstack despite having a server, not using markup, and not being pre-built?

Also, when I look at https://jamstack.org/examples/

There is only a single stack using MondayDB and no mention of SQL anywhere. So, are these all mostly static sites? Is anyone building actual “apps” with this framework?

4

As you pointed out, a JAMstack setup is

  1. decoupled frontend + backend
  2. pre-rendered static assets served from a CDN.

A Vue application can be considered JAMstack on the condition that templates are not being rendered on the backend. If your Vue application uses server side JS to load content, then that isn’t JAMstack. However, if your Vue application uses client side JavaScript to load content, that can be considered JAMstack. It’s understandably a little confusing since the definition of what is and isn’t JAMstack isn’t binary. Here’s an article for some extra context on whether a SPA is JAMstack: Can a SPA be JAMstack? - DEV Community 👩‍💻👨‍💻

In your setup, if you are using the node backend as an API to hydrate the frontend with data (not HTML or any markup), then you can assume the application to be JAMstack.

5

Now I’m more confused than ever.

You’re saying the app can depend on a web server.

The jamstack.org site explicitly says the lack of a web server is the common factor:

The thing that they all have in common is that they don’t depend on a web server.

I’m not sure what to believe.

The writing at JAMstack seems hyperbolic and lacks precision:

Entire Project on a CDN

Really? My database, customer private info, passwords, customer’s confidential image assets. the entire project on a CDN?

Everything Lives in Git
With a Jamstack project, anyone should be able to do a git clone , install any needed dependencies with a standard procedure (like npm install ), and be ready to run the full project locally. No databases to clone, no complex installs

So I guess that explains why almost none of the JAMstack example projects include a database?

What if we need a database? We’re supposed to read/write all customer info in flat-markdown files, commit to github and redeploy to CDN? Every mutation?

When reading about JAMstack, it seems nearly all the projects I’ve seen are pretty much static sites, or else they are consuming some API, but it doesn’t seem like many apps are richly dynamic apps backed by a database. Does JAMstack require that we replace our database with … what exactly I’m not sure.

Is anyone building a non-trivial app with JAMstack that use a MongoDb or SQL? Or are they mostly all static sites like blogs they get redeployed with every edit (Contentful)?

6

One of the things the JAMstack advocates for is the decoupling of frontend and backend, so the lack of dependence on a server alludes more to that i.e. templates are not compiled on the server at run time, they are instead pre-compiled at build time. To pull a quote from the jamstack.org site:

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

A key attribute of the JAMstack is that sites are not served from an origin server, and are instead served as static assets from a CDN. This means that latency is vastly reduced because CDNs tend to be closer to the user than origin servers. So when the JAMstack refers to “without web servers”, it means serving content via a CDN not an origin server.

This distinction can be confusing especially since we use the term “server” in the web dev world liberally and servers can be where content and templates live, as well as key business logic like authentication and redirects.

All this is to say that the JAMstack never claims that everything should run on the CDN. Making such a claim would be ludicrous, and quite frankly wrong. While edge technologies are developing rapidly, and you can handle redirects and some auth at the edge with cloud flare workers or netlify redirects, edge functionality is far from mature. There is therefore never an expectation that everything should be on the CDN to be considered JAMstack.

With regards to your question about databases, this is what the “A” in JAMstack refers to. As long as your database exposes an endpoint that is accessible to your frontend and exists independently of your frontend that most certainly counts as JAMstack. There are many ways that you can work with Mongo or SQL as a backend db independent of your frontend. Mongo offers Atlas, which is their db as a service offering, and faunadb offers a distributed db that scales quite well and even offers a graphql api. If this is interesting as a workflow, there’s an excellent JAMstack radio episode where the head of developer advocacy at Mongo talks about Atlas. It’s worth a listen, if you have a minute

If you’re keen on learning more about case studies outside of blogs, we’re running a monthly webinar where we walk through case studies of how the JAMstack can be used to build robust, enterprise ready sites. Here’s a past webinar episode on how Victoria Beckham Beauty built an ecommerce solution with the JAMstack.

2 Likes
7

It really does say “Entire Project on a CDN”. So it seems we all acknowledge that isn’t the best copywriting.

image
image876Ă—1000 86.8 KB

I’m not sure what you mean by “an endpoint”. Have you ever queried MongoDB on Atlas from a browser? While it’s true that Atlas is a MongoDB cloud hosting service, the Atlas API isn’t a query interface. It’s for managing your cluster (teams, invoices, etc.) Maybe you’re talking about Mongodb Stitch?

Ah yes, OK, I checked your link. Yeah, he’s talking about Stitch which is a service-layer on top of an Atlas hosted database.

OK but this does clear up some confusion. Basically, JAMstack apps are not accessing MongoDb and SQL directly (which is why I don’t see SQL or MongoDB in any of those JAMstacks.) You need to wrap the database behind an API, or use Firebase or some service that exposes the data store as a REST or GraphQL endpoint. Is that right?

So if I want to update something in the database, make call to the Stripe API, and get an image from Google Cloud storage for the user, I do this all from the browser? Or else wrap that logic up in a cloud function–as a substitute for a always-on server?

8

I think a lot of the JAMstack articles I’ve read are too high-level. They read like marketing speak.

Here’s the best intro to JAMstack I’ve seen. It both concrete and easy-to-follow

1 Like
9

this is also a great explainer

1 Like
10

yes, that’s correct. a common approach is to use a serverless function (we have Netlify Functions to try and simplify the process of deploying them), which allows you to create server- and API-like functionality without actually spinning up a full-on server or API

I hope that helps!

11

in practice we found this to be true

There’s still a place for static sites on the web, but it’s shrinking, not growing, and likely still the domain of developer portfolios and side-projects. Sure, it’s possible to engineer a workflow in 2020 that manages to smoosh together a set of disparate 3rd parties, a version-control-system backed CMS and a bunch of template files into a working (and fast!) site, but the value is questionable. Instead of reducing complexity, the JAMStack just shifts it around.

Security and performance are real concerns and will undoubtedly continue to plague developers, library authors and product owners as long as software development lives, however, the solution won’t be found in a reduction of responsibility.

It’s fitting that we have taken the simplest form of a website — static HTML — and transformed it into a complex landscape of build processes, tooling and services that more than rivals the complexity it set out to supplant.

12

Technology is just a tool; if our vision doesn’t match yours, you are definitely not obligated to agree with us or any opinion. We have our vision and we’re sticking to it, and some will not be interested in coming along, and that’s nobody being wrong, just people having different tastes and codebases :slight_smile:

Thanks for engaging with us on the topic! It has been an interesting conversation to follow.