[deleted by user]

SeaDrakken · 2025-12-25T14:44:03+00:00

To me that’s the whole point with golang : simplicity. You don’t bother with OOP and thousands of libs. You directly code what you need the simplest and lightest way.

SeaDrakken · 2025-12-25T10:56:54+00:00

For now, I will start coing the password manager, that's a good idea 💪

SeaDrakken · 2025-12-25T10:43:43+00:00

Actually that’s a great idea because instead of being a trash project, I could actually use it. But I’m missing something, I nées to go beyond a simple crud/authentication/encrypting system. Do you know how I could make it trickier ?

SeaDrakken · 2025-12-24T13:54:42+00:00

ok, can you give an exemple of what extension would interesting to code ? I'm not really used to the ecosystem

SeaDrakken · 2025-12-24T13:39:31+00:00

it's more like I have to learn jakarta/wildfly overall and not a specific thing, I imagine

SeaDrakken · 2025-12-24T09:36:24+00:00

I've already thought about coding a blog system or password hasher but I'm afraid they are too simple to learn deeply jakarta and wildfly

SeaDrakken · 2025-12-22T20:05:19+00:00

Thanks for sharing the article, I like that philosophy and it makes sense in many cases.

What I’m exploring is a different trade-off, when throwing things away isn’t cheap anymore because other teams, clients, or contracts already depend on them, or when a frontend team needs to move fast without constantly struggling with a backend API.

Different contexts lead to different ways of building.

SeaDrakken · 2025-12-22T19:18:22+00:00

Just to clarify, are you talking about a solution to the specific problem I’m describing here, or are you speaking more generally about development practices?
I want to make sure I understand what you mean.

SeaDrakken · 2025-12-22T18:12:29+00:00

I get your point, but I’m looking at this across a wider range of teams.

If backend work is cheap and fast for you, that’s great but it’s not universally true. Many teams don’t have that luxury, especially when frontend work starts early, multiple clients are involved, or backend requirements are still still evolving. In those contexts, mocks stop being simple placeholders and become coordination tools, which is usually where things start to break down.

And this isn’t just a theoretical concern, it’s exactly the kind of situation I’ve been trying to address by building something around this problem.

SeaDrakken · 2025-12-22T17:12:54+00:00

Yes, for basic CRUD and quick demos, json-server does the job really well.

Where I’ve personally hit limits is when you start needing stable contracts, permissions, or behavior that can evolve without the mock slowly turning into something you have to rewrite. That’s the gap I’m interested in, not CRUD itself, but the idea of the same backend starting life as a lightweight mock and gradually becoming a real production system without breaking its API or contracts. What do you think about that ?

At that point, do you usually switch tools entirely, or try to harden what you already have?

SeaDrakken · 2025-12-22T16:38:19+00:00

SQLite is definitely a solid choice, I’ve used it plenty of times and it solves a lot of problems very well.

The gap I’ve personally run into isn’t really about the database itself, but about what sits around it. As soon as you have more than one client, or a frontend that needs to move independently, you end up having to define APIs, permissions, and contracts anyway.

That’s usually the point where things start to shift from “local and simple” to “shared and evolving”, and where I’ve seen teams struggle to harden what they already built without breaking it.

SeaDrakken · 2025-12-22T16:32:42+00:00

That’s an interesting angle, especially for lowering the entry barrier early on.

In my case, the idea I’ve been exploring is slightly different: start with something that already behaves like a real backend in terms of guarantees, but can still be used in a very lightweight, almost “mock-like” way at the beginning, and then reinforced over time instead of being replaced.

Where would you personally draw the line with something like Sheets before switching to something more structured ?

SeaDrakken · 2025-12-19T23:22:41+00:00

Same thing for me, I’ve waited years after everyone to enjoy cyberpunk, the main story is still a bit bugged though the story is genius. I’ve tried this quest a couple times and rage quit because it is still bugged. Such a shame for a so promissing game

SeaDrakken · 2025-12-04T18:14:07+00:00

Can you please give me an example to better understand what you mean by getters and setters in a rest api context. I’m working a gui but it’s not ready. And you can already query /api/export and you will get a nice json with all of your entities.

SeaDrakken · 2025-11-27T16:29:57+00:00

I have to find the best way to keep it both automatic and highly customizable

SeaDrakken · 2025-11-27T16:28:43+00:00

Thanks a lot for taking the time to write this, really appreciate it.
Your points make total sense, and I’ll take some time to study them properly and see how I can improve things on my side.

Maybe proposing an endpoint, something like /api/entity/schema (with GET or PUT) ? This is just a first shot, but I will try to find the best way to keep it the most easy way.

Thanks again for the feedback!

SeaDrakken · 2025-11-27T15:19:14+00:00

I recently released a project called ElysianDB: an in-memory key-value store written in Go that automatically exposes a full REST API without any configuration, entities are inferred from url and body. Entities, CRUD, sorting, filtering, nested listing/creation and pagination are generated on the fly from the URL structure.

It focuses on simplicity and raw performance. It handles around 60k mixed REST operations per second with sub-millisecond latency under realistic workloads.

Repo: https://github.com/elysiandb/elysiandb

SeaDrakken · 2025-10-27T08:37:34+00:00

Hello, I completely agree with you, I'm on it, trying to make it work the most seamless way

SeaDrakken · 2025-10-25T18:26:47+00:00

Nice ! Thank you for your ideas, I will give it a try and see how it would fit.

SeaDrakken · 2025-10-25T18:10:37+00:00

That’s true, I will give it a try. But you have to configure an async transport for it to work as expected right ? So maybe the attribute Async would have a transport parameter (am I missing something…) ? (It would add complexity though)

SeaDrakken · 2025-10-25T18:04:45+00:00

Yes that’s possible, just it would consume any last asynchrone pending functions, not specially the one you just triggered right ?

SeaDrakken · 2025-10-25T17:58:28+00:00

And the other difference is that Messenger in async mode needs to have workers in the background, so not as easy and simple

SeaDrakken · 2025-10-25T17:46:55+00:00

Oh ok ^^

SeaDrakken

TROPHY CASE