I’ve been working on my first open-source framework in Go, called Anclax.
The main ideas:
- One Postgres for all: Postgres here is not only the database, but also the message queue， maybe more in the future — while still allowing seamless migration to Kafka or other BIG systems later if the project grows.
- Built-in modules: starts with async/event queue, later may include more common services in web dev.
- Definition-first: use OpenAPI spec to define HTTP, SQL to define schema/queries, etc, then generate the glue code.
- New attempts: for example, macaroons tokens for auth.
- Convention over configuration: reduce hesitation, do more with less setup.
I’m an independent developer who often builds small projects. Over time I found myself repeating the same work again and again, so I turned that repetition into Anclax.
This is my first time releasing a framework. I don’t have much experience with open source projects, so I’d really appreciate feedback and discussion.
Why focusing on serverless? How cron jobs work in such a environment? They spin up another function? How do you deploy those functions?
mikecwang•4mo ago
> Why focusing on serverless?
I personally love serverless for its low cost and ability to handle potential burst. The framework would try to adapt serverless but it is not a focus (I will change the README later).
> How cron jobs work in such a environment? They spin up another function?
While deploying in the long running machine is the best practice for now, I usually deploy the worker with serverless functions + a cron trigger (5 sec interval). I plan to develop a dedicated trigger to invoke worker when there is an event waiting for handling.
Overall, the framework will adapt the serverless environment, but not focusing on serverless.
> How do you deploy those functions?
In production, I deploy the server in serverless environment like AWS Lambda, with worker-mode turned off (in that case, server will not pull tasks from the queue), then I deploy the woker in long running machines like AWS ECS.
mikecwang•4mo ago
The main ideas:
- One Postgres for all: Postgres here is not only the database, but also the message queue， maybe more in the future — while still allowing seamless migration to Kafka or other BIG systems later if the project grows.
- Built-in modules: starts with async/event queue, later may include more common services in web dev.
- Definition-first: use OpenAPI spec to define HTTP, SQL to define schema/queries, etc, then generate the glue code.
- New attempts: for example, macaroons tokens for auth.
- Convention over configuration: reduce hesitation, do more with less setup.
I’m an independent developer who often builds small projects. Over time I found myself repeating the same work again and again, so I turned that repetition into Anclax.
This is my first time releasing a framework. I don’t have much experience with open source projects, so I’d really appreciate feedback and discussion.
Repo: https://github.com/cloudcarver/anclax
BinaryIgor•4mo ago
mikecwang•4mo ago
I personally love serverless for its low cost and ability to handle potential burst. The framework would try to adapt serverless but it is not a focus (I will change the README later).
> How cron jobs work in such a environment? They spin up another function?
While deploying in the long running machine is the best practice for now, I usually deploy the worker with serverless functions + a cron trigger (5 sec interval). I plan to develop a dedicated trigger to invoke worker when there is an event waiting for handling. Overall, the framework will adapt the serverless environment, but not focusing on serverless.
> How do you deploy those functions?
In production, I deploy the server in serverless environment like AWS Lambda, with worker-mode turned off (in that case, server will not pull tasks from the queue), then I deploy the woker in long running machines like AWS ECS.