[Discussion] Unit of Work Accumulation

[ryankauk]

Hey there, I wanted to get your thoughts on the unit of work during requests with your current implementation. As it it right now, if you fetched your api once mikro would go to the database to get the object and then store it in it's unit of work. If you fetch the second time it will grab from it's unit of work. Depending on what you're doing on the handler and if it has authentication the unit of work will become unreliable in these scenarios. Have you ran into this issue?

I ended up wrapping all my logic inside the RequestContent.createAsync but this would have to be done on every endpoint. Was just wondering your thoughts on this.

[tolgap]

I agree, this repo is a very optmistic way of doing things. Starting your ORM inside an API route handler? That will scale very poorly.

[jonahallibone]

Hey guys -- this repo was created originally when I intended on using mikro in a blueprint for future projects. It was also intended to be consumed in a serverless environment which didn't seem to have a usable solution without creating too many connections to the DB without a proxy. This repo worked for my uses at the time, but has become outdated and is not maintained anymore. If you have a better way of handling mikro in Next for serverless, feel free to fork and PR, or ask the author of the mikro repo to replace my example with yours.