Live data from Hacker News

Show HN: Caffeine – Minimum viable back end for prototyping

github.com

61–70 of 83 posts

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

#61

Earlier quoted context omitted.

Pretty sure this is meant for prototyping and maybe demoing in controlled environments. As soon as you involve auth, things get boring and annoying.

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

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

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

Since we are collecting :) there is also a streaming service https://www.caffeine.tv/

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

#63
post #16
post #2

A very basic REST service for JSON data - enough for prototyping and MVPs! 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 container

Just a heads-up, you might want to take down the example website. Now that it's been posted to HN you might see malicious actors. I also think it's prone to SQL injection at the moment? At least, it's raising a syntax error when inputting an apostrophe.

>>Now that it's been posted to HN you might see malicious actors.

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.

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

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

It really isn't. There are off the shelf libraries and you can keep JWTs alive forever. You don't have to do refresh tokens, etc.

Bare minimum JWT implementation is easy.

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

#65
Shameless plug: along the same lines, but for rapid web UI prototyping cases where you don't want to waste time with setting up a server, I built a tiny tool called REM[0] a few years ago.

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.

[0] http://rem-rest-api.herokuapp.com/

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

#67
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?

Imagine if Gosling had gone with Oak, there are so many more trees to work with.

Of course Indonesian islands were the other possibility...

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

#69

Earlier quoted context omitted.

Are you saying that %v should be avoided in general, or just in the context of queries? (Go noob who doesn't understand %v)

First, don't build strings like this for sql. But for other strings built with sprintf, yes I am saying don't use %v unless for debugging, it's just one more avenue where you might be surprised by input, even if you're not building strings for sql. For example, someone might do this with user supplied data: myoutput := fmt.Sprintf("user:%v",userID) and if userID is a string like "foo" it'll end up in their string and…

Thanks for the explanation! That is a good point about being data-aware.
Post reply on HN