Roadmap
This section talks about the upcoming releases, and the requirements for each and also describes the general gist of each release.
Each release will define the features that are planned for the release, these features may be added to, removed, or moved depending on the progress for that release.
Each release will be named after a random fruit that would be good as/in a fizzy drink (IMO), like raspberry. 👌
V1.0.0 - Cherry
Overview
This release focuses on stability, this is ensuring that there are no major bugs or issues with the framework, and ensures all packages are doing what they should.
Features
| Status | Description |
|---|---|
| ✅ | @sodacore/discord package. |
| ✅ | |
| ✅ | Implement authentication support within the context menu controls for the @sodacore/discord package. |
| ❌ | Document the OAuth2 authetication for the @sodacore/discord package. |
| ❌ | Implement more helpers for @sodacore/discord package when crafting prompts and responses. |
| ❌ | Refactor the @sodacore/core CLI scripts handling service to be more robust and less error-prone. |
| ❌ | Create the @sodacore/i18n package and then ensure all packages can utilise this feature for errors, messages, etc. |
| ❌ | Remove @sodacore/ws's reliance on @sodacore/http so that a WebSocket can be setup without needing to create an HTTP server. |
| ❌ | Implement a queue system that is powered by a thread worker, have this a default feature in core. |
| ❌ | Finalise the @sodacore/di package, including implementing auto-DI for @Injectable classes (Drop the feature if not able to implement cleanly). |
V1.1.0 - Lime
Overview
This release will focus on additional packages that revolve around user interfaces, the framework is primarily a service handler, where various packages offer a service that is exposed, and the framework offers a kind of "opinion", i.e. all packages are built around the same idea, and the same way of doing things, this will allow for a more seamless experience when using the framework. In this release we want to focus on creating almost a way of creating a visual view of building web pages. For example a user could make a simple blog or an admin dashboard.
Features
| Status | Description |
|---|---|
| ❌ | Implement the @sodacore/vite package offering the Vite dev server with HMR, and production static builds and even offer a way to deploy a SSR version as well. |
| ❌ | Implement the @sodacore/ui package, this will be a functional user interface based around the PageVue idea, where users can create, and implement their own pages using a set of pre-defined components, with the ability to integrate "other" packages and their components. |
| ❌ | Implement CORS support with in the @sodacore/http package. |
Future
This is a collection of potential features that we would like to implement, when, how and what that might look like are very much in the air, but we define a basic idea of what that might be.
Feature: Flow Protocol
This is a flow-based processing protocol, the general idea for this is to implement a standardised way of creating a flow of changes, like Node RED, etc, but in code. Think of this, you get an email, and you need to extract data from it, save the images, and then send a message to a Discord channel, this could be a flow.
Let's think about the steps here (only an example):
- Receive the email.
- Extract the data from the email.
- Save the images to a folder.
- Replace the images in the email with locally hosted images.
- Send the email to a Discord channel.
That is a set of nicely defined steps, that could be a flow? Well what if we have a service that could deal with these steps and could take the flow, run it, any failures can return a problem.
The sodacore package would have multiple parts, the flow builder, which is a typed interface for creating flows, the flow engine, what actually runs and handles the flows from A to B, and then flow runners, which can then execute the flows, we would then ensure that a flow runner can be a sodacore application, this means that your sodacore application can effectively be a flow runner and flow initiator, meaning it can be used for local flows, or a mixture, additionally, you can use only external flows, the aim is that the flow defines a set of steps and ways to speak to external services.