Live data from Hacker News

Show HN: Caffeine – Minimum viable back end for prototyping

github.com

71–80 of 83 posts

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#71
post #61

Earlier quoted context omitted.

> As soon as you involve auth, things get boring and annoying. No, JWT is easy enough to implement.

JWT is crazy annoying compared to "pass an API key" in the header.

> JWT is crazy annoying compared to "pass an API key" in the header.

An API key and a JSON WEB TOKEN have a completely different purpose. API keys don't solve authorization.

A single JWT provider can authorize many different servers.

Furthermore Go already have several good JWT libraries.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#72
post #66

Sorry if this is a little off topic, but what is it with devs and naming projects Caffeine? Am I the only person who rolls their eyes when I see another Caffeine / Coffee named project?

I wish devs would stop naming EVERYTHING after common english words; it makes stuff 10 times harder to troubleshoot unless you already rank high on the search results.

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...

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#73
post #61

Earlier quoted context omitted.

JWT is crazy annoying compared to "pass an API key" in the header.

> JWT is crazy annoying compared to "pass an API key" in the header. An API key and a JSON WEB TOKEN have a completely different purpose. API keys don't solve authorization. A single JWT provider can authorize many different servers. Furthermore Go already have several good JWT libraries.

And JWT's don't solve authentication which was the actual problem people were looking to solve. For a prototyping server authn==authz is more than fine.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#74
post #73

Earlier quoted context omitted.

> JWT is crazy annoying compared to "pass an API key" in the header. An API key and a JSON WEB TOKEN have a completely different purpose. API keys don't solve authorization. A single JWT provider can authorize many different servers. Furthermore Go already have several good JWT libraries.

And JWT's don't solve authentication which was the actual problem people were looking to solve. For a prototyping server authn==authz is more than fine.

> And JWT's don't solve authentication which was the actual problem people were looking to solve. For a prototyping server authn==authz is more than fine.

Re-read the OP

> 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.

this is authorization, not authentication. Your assertion is false at first place.

Your comment makes no sense by the way. You'd have the exact same issue with another authorization scheme, the credentials need to come from somewhere.

There no such thing as "prototyping servers" in the wild. Only blatantly unsecure open source servers.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#76
post #20

FYI, there is a name clash with Caffeine, a Mac OS menu bar app that keeps the screen awake: https://intelliscapesolutions.com/apps/caffeine . But I guess this is expected with a name like this, and the scopes of the projects are clearly different, so this should be relatively harmless.

Caffeine is also a central nervous system stimulant of the methylxanthine class.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#77
We tried to do this back in 2016 with BrightWork. We got a lot of traction, but it came on the heels of Parse being shutdown by Facebook after acquiring them for a ton of money.

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. :)

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#79

Earlier quoted context omitted.

Parse is still around and supported: https://github.com/parse-community/parse-server

This is bizarre. I spent a good 5+ min looking over the README and documentation site, and couldn’t find out what that project is other than “a backend that runs on Nodejs.” Yeah ok but what is it? Why am I interested? I’m not looking to be sold, just for it to tell me what it’s for. I have some assumptions based on how I got linked there, but this is surprising to me.

In a nutshell a place for your web page or mobile app to store and retrieve data. There is some auth, business logic / security stuff but not as much as you get in an MVC web app. Let’s you build apps where a lot of the work happens on the front end and the back end is basically a place to save to disk.

Parse was a startup but they shut down and open sourced their code.

Re: Show HN: Caffeine – Minimum viable back end for prototyping

#80
post #42

Earlier quoted context omitted.

You're right of course, but I think the idea of this software is that the user (and, by extension, their input) are trusted.

> You're right of course, but I think the idea of this software is that the user (and, by extension, their input) are trusted. No, you should enforce the most basic security practices even if the users are "trusted". Somebody might put that on the internet for a demo for client and get hacked in no time, because the code is opened to SQL injection. This isn't acceptable. There are minimum security standards every pro…

I'm not sure what you are "no"-ing. I agreed with the parent comment.
Post reply on HN