Short term goals for HTTP server

[siennathesane]

Now that the original maintainers were graciously willing to allow me to help with the vision and execution of this project, I wanted to talk about some of the things that I am thinking of for the project. As I helped with the HTTP server, a lot of my focus is geared around it's implementation and improving upon it's implementation. It was a great 1.0 version, but it definitely has a long way to go before I consider it to be production ready.

I wanted to start a discussion around where it's current short comings are that I want to fix relatively quickly and some short term goals I think would be nice to have. I would like feedback on these items and would love to hear if you think there is a better idea we can go down.

Quick fixes that I want to wrap into what I think should go into a 1.2 release:

• [ ] SSL support. Security should always be the focus, and I want to to be a default config. I'm thinking of having a flag similar to -IWantNoSecurity or something where the operator has to opt in. Let's Encrypt as an SSL provider has made free, trusted certificates so readily available that I would like to make sure we have high standards for security. Until I joined, the original maintenance and development team has had high standards, I want to continue that legacy.
• [ ] Authentication for the API for adding items to the cache. Since security is important, we don't want an attacker to be able to just overload a public cache and crash it repeatedly. I currently don't think reads should be authenticated at this point, but I'd be more than open it in a later version. Currently I'm thinking of a master API key that can be set when the server is initialised. MVP on this would be a CLI flag.
• [x] CLI deliverable for release. It would be good to have separate binary downloadables for the HTTP server when we release a new version. That way operators/engineers can quickly get up and running without needing to compile themselves.
• [ ] Deployment manifests? This one I'm on the fence about. Full disclosure, my employer is invested into the core project maintenance with Kubernetes and Cloud Foundry. I personally do not have a role in that maintenance, but I do like consuming both projects for personal use. I'm thinking of adding reference deployment manifests for both Cloud Foundry and Kubernetes, so if a user does have the code base, they can just push the HTTP server with some defaults. While my focus with this idea is to promote the available of this awesome project, it's definitely not a priority. I'm okay with pushing this off til someone asks for it or one of us decides it's more important than it is now.

Would love to get some feedback on these items. I haven't started the work yet but would like to soon.

[janisz]

+1 SSL support. +1 to Deployment manifests? I think we can start with simple docker container and template of deployment to K8s, Marathon etc. +0.9 CLI deliverable for release. – I'm not sure if I understand correctly. Can we just add the compiled binary of a server to our release page? +0.1 Authentication for the API for adding items to the cache – I'd like to start with a proposal of what we need with it.

[siennathesane]

+1 to Deployment manifests? I think we can start with simple docker container and template of deployment to K8s, Marathon etc.

Sure, great place to start.

+0.9 CLI deliverable for release. – I'm not sure if I understand correctly. Can we just add the compiled binary of a server to our release page?

Yes, this is what I am referencing.

+0.1 Authentication for the API for adding items to the cache – I'd like to start with a proposal of what we need with it.

Sure, I can write one up.

[agoalofalife]

@janisz @mxplusb Hi there! I decided to write here and propose something. Well, How about a few extra endpoints for your server API? It would be nice add

• clean all keys(like reset)
• maybe get and set multiple keys Anyway, clean is first If you are glad to hear it I might add it later, What do you think? 🙂

[janisz]

Sounds good to me. I feel like the HTTP server is not super popular but I'm open for improvements :)

[siennathesane]

Well, How about a few extra endpoints for your server API?

Sounds great! Tbh, it prolly needs a large overhaul since I wrote it years ago to solve a simple problem.

[agoalofalife]

@mxplusb it's worth use a library for routes or some custom implementation?

[siennathesane]

@agoalofalife how modern do you want it? I think we're at about the limit of what I originally intended, which was basically a quick and dirty expose of the internal API.

If I was doing a proper modernization, I think I'd likely introduce protobufs, Connect (adds JSON & streaming support), and HTTP/3. I think that's a bit more than what should go in this repo, but I'm happy to do it as a side project. I have some other things I might want to do as well, like replication, etc.

Thoughts?

[agoalofalife]

emm... It seems too complicated for me. At the moment, I planned to add one endpoint for reset cache. So I will be able to add this one like it was before. Implementation is depend on URL.

DELETE      /api/v1/clear
DELETE      /api/v1/cache/clear  
#but may be ambiguous
DELETE      /api/v1/cache
#it looks like  REST

[siennathesane]

I'll defer to the current maintainers since I don't really maintain this anymore :)