Odd "best practise" about jamstack.org HOT 5 CLOSED

This doesn't sound like a consequence of the "JAM stack", but as a side effect of connecting your local environment to an external API, hence not having the whole project.

The idea here is that when you use a JAMstack approach, you no longer have to have the whole project running locally. This could be because you're connecting locally to an external API, or it could be that you're working with files that are stored directly in the repo, rather than in a DB.

Contrast this with a frontend developer making changes to a WordPress theme or Rails app. In both of those cases, even after installing and running a local LAMP or Rails server, the developer can't see their changes on actual content without either creating a dummy DB with sample content, or cloning the actual DB. This step is unnecessary with a JAMstack approach.

Of course, the frontend is only half the story. If a JAMstack project connects to a backend API, then a backend developer contributing to that side of things would of course need to do a local install of whatever powers that API. However, the backend code is in a completely different project from the frontend, and the install again is simpler.

The key is that the component parts are decoupled, so contributors to one part don't need to install all the parts for local testing and development.

from jamstack.org.

I use a BaaS approach with Serverless and check my API in with my front-end code, FYI

from jamstack.org.

Oops, I didn't mean to close this! I do a lot of work in Intercom, and in that, my default action is to "close and comment." Sometimes muscle memory kicks in over here! 😬

from jamstack.org.

@jhabdas In your approach, I would say that AWS Lambda and the Serverless framework would be the separate "backend" projects in that case.

from jamstack.org.

I suppose that depends on how one defines separate. Here's an example Serverless service checked in alongside a Jekyll repo. Tomato tomato. 😜

from jamstack.org.