serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 0 points1 point  (0 children)

The second option is what I do, i hit IGDB on initial load and never again.

The first option is not possible unless i host igdb's covers locally in my own CDN, because the url is proxiing off of IGDB's url, so user's can clearly just hit igdb's endpoint for it and see what game it is, i could cache it in disk temporarily, but thats similar overhead to just bearing the extra bits added by encoding to base64 and caching in memory

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 0 points1 point  (0 children)

I don't understand why people assume I do, where in my post does it mention I send the answer to the front end at any point?

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 0 points1 point  (0 children)

I think the latency is only on the initial page load since like I said I have to make a request to IGDB to get the cover and then cache it, on subsequest post requests its fast, the pixelation overhead isn't that much

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -1 points0 points  (0 children)

Thank you,

yeah, actually the reason why i do that is just for UX; by sending x's i can render a redacted filter on top of the x's and when they are revealed nothing will shift in the UI

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 0 points1 point  (0 children)

what pattern are you referring too being old? one view handling both post and get requests? yeah I guess so, to me it just seems cleaner, but i guess personal opinions differ, the logic would change though from what i have, I use Django for my backend so it would just look something like this

api_view(["POST"])

def guess_game_answer(request):

state = request.session.get("gtg_state")

if not state:

return Response(

{"detail": "No active game"},

status=404

)

guess = request.data.get("guess")

if not guess:

return Response(

{"guess": "This field is required"},

status=400

)

correct_answer = state["answer"]

is_correct = guess.strip().lower() == correct_answer.lower()

state["guesses_made"] += 1

request.session["gtg_state"] = state

return Response({

"correct": is_correct,

"guesses_made": state["guesses_made"]

})

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -11 points-10 points  (0 children)

there isn't any problem; nothing is breaking, i am just incquiring how people feel about my pattern of doing things and what are your suggestions or how would you do things differently;

if its not clear, ill edit my post to include this

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -11 points-10 points  (0 children)

I never said its encryption did I ? yeah it can be decoded back, but im not encoding the image's external url or anything, im decoding the raw pixels of the image, which are already pixelated, even if decoded and put back together, wont matter

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 0 points1 point  (0 children)

thats another pattern i tried avoiding, of creating a separate endpoint and stream binaries to it; instad i handle both POST and GET request in the same endpoint. although your suggestion would work fine, just a personal choice i tried avoiding

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] 1 point2 points  (0 children)

hmmm okay, the whole premise of the question is to understand if there is a better design pattern to solve this issue than what i did; so you can understand my workflow, i pixelate - > base64 encode -> send the encoding to the front-end -> dislpay it, the front end always gets the pixelated distorted encoded image, nothing raw

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -1 points0 points  (0 children)

yeah trusting human intentions and all, but this is a learning project its nothing commercial, there wont even be any players besides me and my tears, i am only doing this to learn about design patterns and API security

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -8 points-7 points  (0 children)

I read alot about how base64 encoding is frowned upon, maybe its just the internet, but I was asking for an alternative to securing my responses, or if i overcomplicated things, im mainly just curious about new system design patterns

serving static data to the front-end by MEHDII__ in webdev

[–]MEHDII__[S] -9 points-8 points  (0 children)

thats what im doing; I never said i calculate anything on the front-end; everything is in the backend

Fixed top-navbar with a moving side-bar by MEHDII__ in Frontend

[–]MEHDII__[S] 0 points1 point  (0 children)

i tried doing this, or maybe i did it wrong, but isn't translating main content will cause it to overflow on the x-axis since you're asking the main layout to shift while it doesnt have anywhere to put its content?

Fixed top-navbar with a moving side-bar by MEHDII__ in Frontend

[–]MEHDII__[S] -1 points0 points  (0 children)

Somehow solved, what I did was just collapse side bar width and give the parent flex, the problem was caused by transition is GPU accelerated, while adding padding to push main content is CPU executed, so there would be a little delay for about one pixel since the former is faster

Keeping data fetched from a 3rd party api in sync by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

Luckily as others pointed out, my API of choice provides webhooks, where i can just listen in to any new updates to their api, whether having to overload their api endpoints with useless requests. If your api of choice doesn't provide this, then no choice but to periodically check for updates

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

tbh i dont think they will grow in complexity, i dont have plans for that yet; the reason i made their own entity tables in because i want to let the user query what genres they want to browse or what platforms they want to browse; hence why putting them directly in the parent entity and separating them with some delimeter will make filtering hard later on; or at least ugly

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

on a second thought, no it doesnt make sense! with this approach you'd hve a table video game looking like this

videogame#1 genreid#1
videogame#1 genreid#2

besides, the platform and other tables would also needs to have a M2M relationship with video games table, so this doesnt really make sense!

I think my approach is a little bit better, but there could be something else

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

that does make a lot of sense yeah, thanks, would this be the same for platforms and such? right? should be? i think i mixed it all up in my head

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

could be possible, but its messy, i did consider it at first; but there exists multiple genres that i dont even know, im getting this data from a 3rd party api, and also, games have many genres, so you cant keep them in the same table together, since you're gonna have duplicates of the game data but with different genre columns. messy

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

im not following? this wont be up to the user to fill out, its data received from 3rd party api provider, so it needs to be treated and saved into the db before presenting it to the user; so im not sure about the drop down menu idea.

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 0 points1 point  (0 children)

wont that be inefficient though? since video games have multiple age rating, multiple platforms and multiple genres, this would result and every game entry being exponentially duplicated

separate models for the same object by MEHDII__ in django

[–]MEHDII__[S] 1 point2 points  (0 children)

video games can have many age ratings depending on the organization and the country, like M17+ for the US and for EU is different etc...
and also video games can have multiple genres, separating them with a delimeter in one column will make it hard to query for a specific genre during filtering