Currently working with Typescript(both Node & Bun runtime), Python & Go.
Spent majority of my time most writing Scala, and learning Rust in my spare time.
I specialize in architecture and coding of asynchronous distributed systems, but talk to me about anything tech. Currently also working on full stack development with HTMX.
Currently, we load all the data from the backend for payments and order history. This isn't feasible in a real-world application due to causing performance issues on the DB, network bandwidth ie.
This issue will track adding pagination functionality.
Acceptance Criteria:
Add limit/offset db queries for all API endpoints requiring pagination
While the additions in #32 are great, the routes files are quite large now, containing a lot of Swagger and request validation data.
The routes files should be made much smaller than they are by adding two new files on top of the index.ts routes we currently have, validations.ts and swagger.ts.
The validation and swagger objects already exist in index.ts, so it's minor code refactor.
This will however have a large impact:
Much easier to follow API routing without getting distracted by the metadata
We can easily expand metadata information much more than we currently do, especially the Swagger documentation. it will be in it's own module, so there won't be any issues with creating any bloat on the routes file.
Ensure this is done only after addition of unit tests #16
For this project, we're aiming to highlight HTMX integration on the front and back end.
Configuring tailwind would be a win, but will add more complexity to understanding the essence of the desired outcome, rendering dynamic HTML on the front end without a conventional JavaScript framework doing the heavy lifting.
Pico CSS already has decent styling for the UI, no need to complicate things further in this regard.
This ticket tracks progress to purge any tailwind-related JS, CSS, and configurations.
Since user's data is now available, the application should also record who completed a payment. This ticket also includes listing of who completed the payments in the payment details list.
Currently, Zod validations are failing because query params and bodies that expect numbers to be sent are numbers wrapped as strings, so Zod numbers validation is failing.
Would also be great if we can handle this at the top level so that we don't have to repeat the logic in every route.
We fixed the runtime and compile time parsing of query params and request bodies in #10
However, theoretically, we're still not returning BAD REQUEST status codes for failed Zod validations, we'll get an internal server error, and the response will be JSON with the Zod validation errors.
This should be changed to a bad request and instead of JSON, an info-wrapped HTML component may be injected into the document markup.
Stays in the backlog for now as not a blocker for next release phase.