[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]

/tech/ - Technology

"Technology reveals the active relation of man to nature" - Karl Marx
Name
Options
Subject
Comment
Flag
File
Embed
Password(For file deletion.)
Not reporting is bourgeois
[ Return / Go to bottom ]

File: 1749496513522.png (43.89 KB, 1920x1080, 2025-06-09-144547_1920x108….png)

 

Started work on a new project a few days ago.
Previously was working with Starlette, SQLAlchemy, and Jinja, vanilla front-end, and only recently Docker.
With this was able to build some cool AJAX applications, but the method of doing so was a little crude.
Through job searches found that many employers were interested in Typescript, React, and some in FastAPI.
There were also tons of listings asking about LLM usage either as tooling or through the API.
Further decided to actually write tests for my software this time, previously only ever testing, live, in situ.
Anyway a 630MB folder later and have gotten OAuth2 authentication with a JWT token, and React login screen to work.
Very close to the entire project has been written with an LLM, or by modifying examples.
This has fealt time consuming at times mostly in testing, specifically setting up mocks and fixtures.
But really it's only been three days to get a pretty well tested (the front-end still needs a little more) application.

Only three days for something extremely simple that has been done a million times already? Impressive!

>>30141
Yah, it sounds like a joke, and would be laughing if it wasn't such a pain.
It would have taken twelve lines if it was just Jinja, Flask, and SQLAlchemy.
Hence the complaint about the 630MB folder, it's p. ridiculous.
Think could've used AuthX which might have saved half of this tediousness.
Guess could still switch over the backend to use it, even at this point.
But would rather focus on other things.

Got basic querying of OpenAI setup with streaming replies, but not incremental rendering.
The basic idea for the app is to have these ChatBot returns be savable, editable, and linkable.

>>30144
Maybe this project is dead before it even really got started dunno.

File: 1750773979637-0.png (913.35 KB, 3584x2274, prompt.png)

File: 1750773979637-1.png (793.75 KB, 3584x2274, register.png)

Managed to get something presentable built.
Ended up using SSE to stream the text responses.
Switched over to Authx, which did save some trouble.
The whole thing is maybe 50% test coverage.
Am still not really using React components.
It's still almost entirely written with an LLM.
Seem to pretty much understand the code.

>sqlalchemy
Stop using ORMs. Write raw SQL queries.

>>30364
>real men use SQL, raw.
Why though? It just saves a ton of time writing boiler plate and lets me compose parts of queries. This project uses SQLModel.

>>30366
it's fine for a shitty hobby project, especially one that is essentially a garbage CRUD that speaks to an LLM, but on any professional project i would consider it tech debt. it abstracts SQL logic and as any abstraction, it makes a few assumptions for you and is less flexible, so you may want to get rid of it as a project grows and the ORM becomes limited. as i said, a total non-issue for a dime-a-dozen LLM client

>>30369
Have on occasion run into issues where the assumptions are too restrictive. For example wanting to use trigger functions which aren't yet supported by Async SQLAlchemy. Something like https://hugsql.org/hugsql-in-detail/ seems like the best of both worlds, because there isn't a lossy translation layer, you basically just add types. Evidentially pg-promise supports something like this, but there's no types!

/* @name query1 */
SELECT * FROM table1 WHERE id = $1;

/* @name query2 */
SELECT * FROM table2 WHERE name = $1;


On you other comment simply have no ideas or alternatively will for something that isn't a hobby project atm. Only built this to get the words: testing, FastAPI, React, and OpenAI API on my resume. Was recently given two "viable" business ideas, one was an army of web forms and visualizations of this form data, and the other was gluing together API calls, but for some reason have no motivation to implement them.

Am thinking for my next project of using: https://github.com/mrousavy/react-native-mmkv, and https://docs.slatejs.org/ to build a React Native Zettelkasten application like Obsidian. Which is something have been trying for way to long to implement.

>>30370
HugSQL looks like a DSL rather than an ORM so it's going to avoid the usual ORM pitfalls,looks cool btw,didn't know about it

>>30364 (me)
>>30366
Well, ORMs tend to tightly couple your application code to your database schema, which is my reason for avoiding them entirely. You need to keep track of all your migrations and even then if something breaks, it might permanently ruin your database. This is why I try to use the most generic interface possible when interacting with databases with the least amount of abstractions, which in this case is SQL. As long as you don't do anything stupid, raw SQL is fine. But as another anon already mentioned, you're building a hobby project and it'll probably work just fine even if you don't write raw SQL queries.

>>30374
In this application there was a loose coupling between the table UserInDB and the rest of the application. Even though the data is ultimately stored in UserInDB what's passed around are User and UserCreate objects. Ended up really liking this structure, but only understood why after you mentioned this.

class UserCreate(BaseModel):
    username: str
    email: str | None = None
    full_name: str | None = None
    password: str

class User(SQLModel):
    id: uuid.UUID = Field(default_factory=uuid.uuid4, primary_key=True)
    username: str = Field(unique=True)
    email: str | None = Field(default=None)
    full_name: str | None = Field(default=None)
    disabled: bool = Field(default=False)

class UserInDB(User, table=True):
    hashed_password: str

async def get_user(session: AsyncSession, username: str) -> User | None:
    user_in_db = await get_user_in_db(session, username)
    return User(**user_in_db.model_dump(exclude={"hashed_password"})) if user_in_db else None

async def get_user_in_db(session: AsyncSession, username: str) -> UserInDB | None:
    result = await session.execute(select(UserInDB).where(UserInDB.username == username))
    return result.scalar_one_or_none()

>>30377
nope, still dim.

>>30374
Am talking too much and thinking too little; for unknown reasons.
I'm disappointed, and cooked.

A query builder lets you conditionally chain parts of queries.
This is unlike PugSQL, HugSQL, or pg-promise.

You're perfectly free to translate from the ORM objects to other objects.
So the coupling to the database schema shouldn't really be an issue.

Really the only substantial issue can understand at my level is missing features in the ORM.
This is like for example the missing TRIGGER functionality for Async SQLAlchemy.


Unique IPs: 5
[Return][Go to top] [Catalog] | [Home][Post a Reply]
Delete Post [ ]
[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]
[ Return / Go to top /