|
|
|
@@ -6,20 +6,32 @@ Yes. |
|
|
|
|
|
|
|
> No, but seriously? Why JavaScript? |
|
|
|
|
|
|
|
I find it comfortable to create stuff in TypeScript. However, the reader must pay attention to the underlying architecture instead of the specifics of the platform being implemented on. |
|
|
|
I find it comfortable to create stuff in TypeScript. However, the reader must pay attention to the underlying |
|
|
|
architecture instead of the specifics of the platform being implemented on. |
|
|
|
|
|
|
|
> Then why another framework? |
|
|
|
|
|
|
|
Most frameworks focus on the routing and the logic side of things. This is reasonable for most applications. However, the benefits of hypermedia becomes an afterthought, wherein attempts to produce rich structured data become ignored (as compliance with Web standards is not a requirement for building Web services, however developers comply with some aspects of REST in order to create some rudimentary RPC service). |
|
|
|
Most frameworks focus on the routing and the logic side of things. This is reasonable for most applications. However, |
|
|
|
the benefits of hypermedia becomes an afterthought, wherein attempts to produce rich structured data become ignored |
|
|
|
(as compliance with Web standards is not a requirement for building Web services, nevertheless some developers comply |
|
|
|
with select aspects of REST in order to create some rudimentary RPC service). |
|
|
|
|
|
|
|
> What's the point then? |
|
|
|
|
|
|
|
The goal of the framework is to empower developers on focusing on the business logic while not being hindered by considering proper REST (and ultimately HATEOAS) guidelines on the resulting implementation. |
|
|
|
The goal of the framework is to empower developers on focusing on the business logic while not being hindered by |
|
|
|
considering proper REST (and ultimately HATEOAS) guidelines on the resulting implementation. |
|
|
|
|
|
|
|
> Why didn't you extend $FRAMEWORK instead? |
|
|
|
|
|
|
|
Frameworks tend to include a lot of built-in plugins/code. I opted on using a minimal setup for a truly compositional |
|
|
|
API (add any languages/media types/request handlers/request decorators etc.), however defaults are provided sensibly |
|
|
|
(default response is serialized as JSON because it's already a ubiquitous media type). |
|
|
|
|
|
|
|
> What is the expected output of this project? |
|
|
|
|
|
|
|
The choices include implementing a plugin to complement popular frameworks, as well as an entirely new framework with adapters to various common components of Web services (such as persistent storage). |
|
|
|
The choices include implementing a plugin to complement popular frameworks, as well as an entirely new framework with |
|
|
|
adapters to various common components of Web services (such as persistent storage). |
|
|
|
|
|
|
|
> What's the timeline for this project? |
|
|
|
|
|
|
|
Indefinite. However I shall provide milestones if necessary for certain periods of time. |
|
|
|
Indefinite. However, I shall provide milestones if necessary for certain periods of time. |
