Glitch is full of all sorts awesome projects people can remix to make their own, but if you’re looking for a quick start or a blank slate, we offer three minimal “hello” projects, where each builds one layer of complexity on the next:

• hello-webpage is a simple static webpage with a CSS and JavaScript file
• hello-express extends hello-webpage with a Node.js server, using express to handle requests and serve pages/data
• hello-sqlite adds a database to hello-express to store information between page sessions.

hello-sqlite is the third-most popular of the starters, and lots of people have used it to explore a new idea. However, the project had a bit of a quirk to it…

It didn’t really use the database!

Why??

When a user views a project on Glitch, they all view the same running instance of that project. When you visit hello-sqlite.glitch.me, you’re talking to the same database that I see when I go there. If the app was to take user input and store it in the database, I'd see the data you put there and vice-versa. For something like a blog's comment section that’s exactly what we want but for a code demo it didn't really make sense. We also didn’t want to risk someone coming along and putting something not-so-friendly in there for all other users to see!

Of course people don't use hello-sqlite directly—they remix it and make it into something else. We found ourselves with a puzzle: how do you make a project behave differently after it's been remixed?

When you remix a project on Glitch, you get a copy of the project's files at the point at which you remixed it, with a few exceptions. We don't copy anything in a special folder called .data, which is meant to hold data specific to that single project. For hello-sqlite, this is where we keep the SQLite database file. We also give special handling to a file called .env. This file is intended to hold secrets you need for your project to work, i.e. API keys, or project-specific variables. The file is a series of variable definitions like this:

# here are my secrets!
API_KEY=b33fcabbage
MY_GREATEST_FEAR=notenoughpudding

When a project is remixed, we remove all the values, but leave the variable names so the person remixing can fill them with their own:

# here are my secrets!
API_KEY=
MY_GREATEST_FEAR=

Thinking about this, the lightbulb went off! We added a variable to hello-sqlite's .env:

DISALLOW_WRITE=TRUE

We then added code to the project that let users add items to the database, but with a check to see if that variable was set:

// DISALLOW_WRITE is an ENV variable that gets reset for new projects so you can write to the database
if (!process.env.DISALLOW_WRITE) {
  // write to the database!
}

This means the sample database writing code is ready to be customized without having to even un-comment it- once you click remix you're set! If a user is also building a demo, they can set DISALLOW_WRITE to true as well to get the same benefit.

Conclusion

Is it a bit of a "hack"? Maybe! I think the solution provides the right balance of being somewhat-clever without relying on giving an app special treatment just because it's made by staff.

Additionally, while adding the new logic we also updated the JS to use widely-supported ES6 syntax and tidy up the documentation.

Try it out!

Thanks to everyone who did code review and helped brainstorm on how to make it all work, as well as all the users who have battle-tested the new starter. If you're looking to build a simple app that stores data to the server, try remixing hello-sqlite and let us know what you think.

Happy Apping!