Twitter client as a static website
IH -
I'm doing some research for a product feature, and need help figuring out something. I'm not a front-end developer (mostly backend), so I need to figure out if it's possible to build a twitter client (mostly for reacting to other's tweets and posting on behalf of the authorized party) as a pure js/static page application.
I've looked into twitter's APIs, and I'm kind of certain it's possible, but not completely sure.
Thanks!
Doable.
Try searching for "JAMStack". Think static front-end hooked up to a bunch of APIs glued together with Markdown/JavaScript. Comes with its own set of headaches.
@robhutters thanks! Sounds complicated :-)
Would you mind elaborating on "headaches"? Also, I'm not sure how would authentication work in this case. If this is an actual client for twitter, I'd have to keep my creds somewhere, right?
Thanks again!
Sure :)
Here's a brief overview:
The token grants access to Twitter's API. JWTs include payloads. You can use that however you see fit. Here's a slightly more involved example:
fetchrequest.(Make sure to protect against CSRF with a CSRF token cookie.)
Headaches:
Don't let that last bit scare you though. You have a fairly straightforward use case that fits the bill. Give it a shot, learn a thing or two. Reassess.
Good luck. :)
@robhutters oh my lord. This is so much more than I was bargaining for. Thank you for such a detailed explanation.
It does feel a bit complicated :-), and it still means it's not a "static" page really if it does have some backend after all. I would now need to look into lots of things in order to understand how to build this stuff.
I guess the path then is always client -><- backend -><- twitter; which is fine too.
Finally, what do you mean by not using jwt tokens for session management? I don't think I've ever done that, but from what I've read, you can use them for managing session if you store them in a cookie...even though that brings a bunch of other problems.
Thanks again!
JAMStack websites are "static" in the sense that parsing data and rendering said data is a decoupled process as opposed to "dynamic" sites like Wordpress that do both server side. Your front-end code is just a collection of (static) assets that live anywhere you want them to, which (typical) "dynamic" websites can't do.
The terms "static" and "dynamic" don't mean what people think they mean in the context of web development. There used to be clear line between them, along with an expected set of functionalities and mode of development associated with them, which is the important bit here. The line between "dynamic" and "static" is blurred now.
All websites have dynamic elements to them, save for maybe a handful of blogs that serve only text, but the key distinction now between "static" and "dynamic" is how they handle the rendering and parsing of data, as far as I'm aware, decoupled or coupled. Don't quote me on this though.
You can use JWTs for sessions if you store them in a cookie. However, cookies can't hold much data at all, at most 4096 bytes. JWTs are nothing but encoded strings of data which can hold whatever info you want, however much you want (limited by memory only). They are a tool to transfer data with, between stateless services. Storing that information in a cookie is not recommended because there are size limitations to a cookie. In the end that's up to you though. I've done it before.
What you shouldn't be doing is storing your session info in a JWT and saving that JWT on the client's computer (e.g. local storage or memory). Don't ever do that.
Fantastic response :-)
Yea, I reckon people use "static" as a way to insinuate that there's no backend in the old sense, that is no webserver running somewhere to serve your requests.
Instead, there's a model that allows the code that's fetching/parsing/rendering the data to live in the frontend, and with JS frameworks it is sort of "static", as in "being served once"; and then use APIs that allow pushing and fetching data. These services are not necessarily running all the time at the backend and could be serverless in their nature.
Alas, who cares the distinction :-)
Thank you for the tokens explanation for the session management. That's exactly what I've read and figured out, so good to get some reinforcement there.
Hopefully, it will all work out. I'm really not a frontend person, and all this frontend is very alien to me. Might be a good lesson in life I reckon.