Taking it even further; how about persisting the data in the file?
Sometimes your prototype will need some pre-added data so I think this might be useful.
It's more complex than Caffeine, but it has a lot of options.
It can also run as a proxy and generate the mocks from actual http requests passing through the proxy
regarding the pre-population, you can just make a quick script with curl that will add some data after you run the service. any thought?
I wonder if parse is still around and supported? I thought that was pretty good for this kinda thing.
One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking.
Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical component.
I have tried to write a universal backend... It's possible, but you really have to work in a permissions model from the beginning. What you'll find is that basic read/write/own enables very basic functionality. Unfortunately, to do anything complicated, you will need to write server-side queries that verify that the user is allowed to do what they are trying to do.
As soon as you involve auth, things get boring and annoying.
No, JWT is easy enough to implement.
Features:
no need to set up a database, all data is managed automagically*
REST paradigm CRUD for multiple entities/namespaces
schema validation
search using jq like syntax
CORS enabled
easy to deploy as containerI also think it's prone to SQL injection at the moment? At least, it's raising a syntax error when inputting an apostrophe.
https://github.com/rehacktive/caffeine/blob/master/database/...
"INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'"
Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli.
I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.
This needs to be an HN fN Masterclass by @Dang....
We should have regular visibility into /how/ HN is used by malicious actors.... HN has enough pedigree to get some insight from some of the top security folks... and it would be REALLY good to know how HN is being harvested in this space.
Jokes aside… chaos engineering is a big deal right now - this isn’t a terrible idea and might be worthy of a fork.
My next application is going to be called Toreutics which is going to break this word for every person that actually uses it.
Kinda like breaking the word Meta. Which I suppose is actually aimed at making things difficult to search for.
If I read it right, you don‘t need to configure any schema to use this? You can just POST a user and it will create that type? If it‘s true, that‘s a real step above hasura/supabase for rapid prototyping.
Am I the only person who rolls their eyes when I see another Caffeine / Coffee named project?
I guess HN would be the best place to bring this up in a psa topic but I doubt it'll have any long-term influence...
Of course Indonesian islands were the other possibility...
https://github.com/rehacktive/caffeine/blob/master/service/s...
It's not "MVP" fashion but even for only one implementation making these interfaces is critical IMO.
That said, if it's not too much maybe consider adding a SQLite backend! :)
I don't think this has a good price-performance ratio - all other solutions I know are cheaper...
Correct me if I'm wrong, as I havent used Postgres in a few years, but doesn't the `json` column in Postgres just store the data as text?
Last I knew, jsonb was much more efficient/performant for queries and storage, while having a very robust api for querying specific properties.
Curious what the reasoning was for using json rather than jsonb.
For this product, if the super-generic API doesn't offer/require a need to do complex operations, though, json may be adequate to lookup items by id and present them.
While not a security risk if done locally, why not just use a where string builder to generate the $ values and a variadic as the input? It's about the same amount of work.
It never actually stores data on the server (it echos it into a cookie instead), so the dataset is only ever visible to you, no auth or service keys required.
The lesson I learned from that experience is that there is still a tremendous amount of distrust in platforms that make it easy to stand up something quickly. Even prototyping.
Even if you make it easy for users to export their code from your platform you will still run into scalability questions (i.e. what happens if someone builds the next Flappy Bird on your platform?).
All that aside, this is great! Congrats on launching Caffeine. :)