Roadmap

[nathanclevenger]

• Initial Implementation #8
• Integrate itty-router & qs for convenience #2
• Figure out better way to have defaults #3
• Define list & pagination url conventions #4
• Add search/filter mechanism to list #5
• Dynamically generate Typescript Types #9
• Support Schema Enforcement and Schema-less config #10
• Implement import functionality #6
• Support idempotency with GETs using a confirmation hash #7

[nathanclevenger]

@AggressivelyMeows this was a very early experiment ... not much was ever implemented, but I really do like the interface:

        endpoints: {
          admin: origin + '/admin',
          types: origin + '/types',
          list: origin + '/:type',
          search: origin + '/:type?key=value',
          create: origin + '/:type/new',
          read: origin + '/:type/:id',
          update: origin + '/:type/:id/set?key=value',
          delete: origin + '/:type/:id/delete',
          import: origin + '/admin/import/:url',
          export: origin + '/admin/export/:url',
          backup: origin + '/admin/backup/:url',
          restore: origin + '/admin/restore/:url',
        }

The premise of CRUD.do is "what if we could have a CRUD API that a developer could use entirely in their browser as GETs without having to need a UI or a tool like Postman?"

So APIs like Upstash (https://docs.upstash.com/redis/features/restapi) really opened my eyes to how GETs could be used for any REDIS operation ... and it's so easy to interact with ... but what if the responses had links to other things, like changing the schema, adding a new record, deleting a record, etc.

We can handle idempotency by using a one-time hash with optional confirmation ... I did a POC of that earlier and it worked great (it used the version hash like Macrometa has) ... but I wouldn't want to prioritize idempotency initially.

I think if we implement this as a simple DO-based database, it could be a great reference architecture. Alternatively, I've been thinking that CRUD.do could actually be more of a library (like an NPM package) that provides a unified view for List, Search, Create, Read, Update (both override PUT style as well as merge PATCH style), and DELETE ... where we could support the actual HTTP GET/POST/PUT/PATCH/DELETE verbs for a very Standard REST-style interface ... but ALSO support all of these methods via GETs.

In any case, I think we should do a simple implementation using DOs to start ... we could always extract the implementation at a later date to use this as a CRUD interface ... but I think we will learn a lot by actually implementing this API.