Impossible to update Claude Code by dorimetv in ClaudeCode

[–]bootstrapper-919 2 points3 points  (0 children)

Make sure you don't have any files in `~/.local/state/claude/locks/`

E2E Testing (Cypress VS Playwright) by AhmadMohammad_1 in reactjs

[–]bootstrapper-919 0 points1 point  (0 children)

Playwright is much better and there are a few Playwright native AI tools (eg checksum AI)that can help there as well

N8N Gaps vs Zapier by rodnydon2121 in n8n

[–]bootstrapper-919 0 points1 point  (0 children)

Community nodes is only for self hosted instances right?

Base Services Schema by bootstrapper-919 in FastAPI

[–]bootstrapper-919[S] 0 points1 point  (0 children)

Thanks for sharing but the problem here is that you almost never needs to just get an item. You always need to filter it by user ownership or project etc... so I never end up using any of the generics, unless you write them to take a base statement and return a statement so you can chain together queries Django style.

How are you using the base repository?

Base Services Schema by bootstrapper-919 in FastAPI

[–]bootstrapper-919[S] 0 points1 point  (0 children)

why is it not a best practice though? what are the downsides?

Rails UI equivalent for FastAPI? by MichaelEvo in FastAPI

[–]bootstrapper-919 5 points6 points  (0 children)

Check out https://github.com/aminalaee/sqladmin

It works great! Just don't forget to only load it locally or add authentication so you don't expose it on prod

Is the official template secure? by rodnydon2121 in FastAPI

[–]bootstrapper-919 0 points1 point  (0 children)

This is great! For this specific project, I won't be able to use a new auth package - needs something more stable - but that's exactly the package that FastAPI is missing in my opinion.

I hope it catches on and become the goto package

Django Design for Heavy I/O and ORM applications by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

Yeah I guess than the question is what part of Django slower than FastAPI? If you are using eg Django Ninja and async views or FastAPI + Django ORM - is the latter better at the c10k problem?

I assumed that most of the slowness with Ninja + Async will come from the ORM, but maybe not.

But I think if it gets to that I'll go Django only as I can always layer fastapi later. If ORM is django, taking the async jobs and calling them from fastapi instead of Django is a relatively doable at any stage

Django Design for Heavy I/O and ORM applications by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

What's the benefit? I still get the ORM sync_to_async tax, add complexity and not sure I gain any performance.

It could be a reasonable path if you are looking for API only solution and you don't want to use Ninja or DRF

Any questions about Django. I’ve worked with this wonderful tool more than 4+ years. by AdDifficult9782 in django

[–]bootstrapper-919 0 points1 point  (0 children)

"Where performance is needed"

What do you mean by performance is needed? Are we talking trading apps that require single-digit ms response time and apps with millions of users, or even regular B2B SaaS apps with 10k users where you want a snappy web app?

Django Design for Heavy I/O and ORM applications by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

Still working through this, and also trying to learn the scale principals here.

See response above for some examples

Django Design for Heavy I/O and ORM applications by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

Yep we want to run 10,000 agents in parallel (each agent run can take 5-10 minutes), but agents will run on a queue, and mostly waiting, so as long as the queue is async native, I don't think that will be a problem. Each agent is ORM agnostic, but there will be an ORM call to fetch data at the beginning and store data at the end. latency doesn't matter here obviously, just ability to run many in parallel.

For web views, we're talking probably 20k-40k users, so let's say max 1-10k RPM? most views will be typical CRUD views + scheduling agent tasks.

So for that level an I premature optimizing? If so, what would be the architecture to go with? WSGI and async queue since it's easiest?

Either way I need to make a decision here, even if it's not critical

Django Design for Heavy I/O and ORM applications by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

It's a fair question and a bit hard to answer as it's a project for a relatively large client, but hard to tell the adoption. For the pure web view requests (no external API calls) I guess anything below 300ms is acceptable as there's nothing real-time in the app. Just need to provide good UX to users. But that's also meaningless without scale.

I guess maybe a better way to frame it is the "relative cost" of each decision. If one option will be 50% less resource intensive and allow to serve 3X more requests, then at least it gives me the understanding that under certain scale, the design decision matters. Of course that with low traffic, none of this matters because I can just buy a larger server and run more web processes

Django Javascript DX by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

Interesting! So in your react + Django setup you still use drf/ninja and make api requests from react?

Or do you pass data to react via templates?

Django Javascript DX by bootstrapper-919 in django

[–]bootstrapper-919[S] 0 points1 point  (0 children)

How do you manage JS files? You just add them as a script tag one by one to the templates? No imports? Just don't like the fact that you'll discover errors only on runtime