## I’ve updated the Service Manager, including the dependency resolver. These changes include:
1. New lifecycle hook "onSetup", intended for setting up databases, etc.
I've mostly added this to split "start servers" and "setup things" all being in onStart. This way the separation between those 2 tasks is clear and helps to eliminate certain race conditions.
2. Toggle switches are now generated automatically
Before you had to manually declare a key in a config in onInstall, and then read it in isEnabled, which was just extra boilerplate. So I automated the process in the Service class.
3. "?", ":after" and ":after?" parameters for dependencies
Before this, the boot order was still fragile even with dependencies defined, because the ability to define a dependency, and make it start only AFTER your dependency is initialized wasn't a thing. Now you can do this by simply appending ":after" to the dependency name. "?" at the end also makes the dependency optional.
4. Few fixes relating to dependency resolution and boot orders
## HTTP API Got a decently big update as well..
1. The performance is now up ~70% from previous versions, finally surpassing FastAPI,
I've achieved this adding an option to disable unnecessary messages from being logged. Which only goes to show how heavy the logging manager I use is, but I doubt I'll be rewriting it, since the way it is now helps with DX.
2. Response validation using "@HTTP.Responses(...)" and ReplyModels:
Before you were able to only validate what's coming in, but not what's going out. The validator has a strict mode, which when enabled adds an extra layer of "security". If strict mode is disabled, the responses are only used for OpenAPI docs generation. Tho the framework may still complain if you're sending invalid responses.
3. Nested object validation and Require.ListOf
4. Static methods in Reply
Since the framework is built on Starlette, you may need to use Starlette's responses in some cases.
5. OpenAPI Docs generation
This was kinda a big thing on my list ever since I realized that I can automatically generate SDKs instead of having to write request calls manually. I also wanted to add a way to expose the docs with an endpoint, but I'm holding off on that.
***
The Package registry & manager were introduced as well. The package registry it itself built on Nautica, and works with the package manager integrated into the Nautica's CLI.
Likewise I've started work on the Landing page & docs website for the framework, but I'm putting it off for a bit, because of finals.
I've also fixed countless bugs, refactored things, and over all made many QoL changes, which helped to make the framework feel more polished.
***
This might be a strange project, since I'm somewhat "reinventing the wheel", but I really didn't like the way FastAPI, Flask and other Python HTTP frameworks work. It basically handles ONLY the http part, which is fine, but in bigger projects YOU have to manage everything else around it. When I was building small apps it wasn't that big of an issue, but it became pretty apparent in bigger projects. The complexity and boilerplate that comes with large projects isn't something I can handle well, while also having to enforce my own conventions.
I made Nautica to fix these issues, and I'd say I succeeded. The boilerplate that's needed per route is minimal, compared to other frameworks; The package manager adds an intuitive way to add plugins (services, packages), and the service system itself does a lot of the heavy lifting for you, by automatically deciding on the boot order instead of you having to write do it explicitly using imports, etc.
In conclusion, Nautica takes away some freedom and in exchange gives you structure, less boilerplate and tools to debug your code, which makes shipping apps easier and faster.
- 9 devlogs
- 25h