#Astro is focused on front-end and content. Should I use some other service for back-end then?

22 messages · Page 1 of 1 (latest)

finite galleon
#

I know there is a build-in way to handle backend stuff like using .js and .ts files as endpoint etc... But as someone new to Astro, I feel like there could be some other and better way to handle the back-end, especially if its more complex than just some endpoints here and there. And I realized that when I noticed the lack of documentation in that regard. I know there are some doc pages that talk about back-end services and some recipes building things like forms an other common things. But I didnt feel like that was a satisfying amount. After reading some of these docs I even gained the urge to build my backend in Java or something else common in the backend such as expressJS.

I know this is more of a subjective discussion to hold, but I just wanted to give my thoughts and receive some in return. Maybe I missed something you never know

fleet wyvernBOT
#
No-one around right now?

It looks like no-one has responded to your question yet. People might not be available right now or don’t know how to answer your question. Want an answer while you wait? Try asking our experimental bot in #1095492539085230272.

prime linden
#

Yeah i had the same thoughts. The Endpoints in Astro are not perfect but you can Work with them . Only downside beeing things like the fetching and typesafety for request. I think the best Option in Combination with Astro is using something like GraphQL there are good docs for it and its even mentioned in the docs.

foggy sandal
#

trpc also has examples for astro if you want typesafety

prime linden
#

Uhh nice thx

finite galleon
#

interesting input so far. I never stumbled upon tRPC before but first looks are pretty nice.

lapis olive
#

hmm, interesting, I did not had such a feeling, but I'm curious to know what brought you to this observation, if you could explicit some more examples.

  • Astro is mainly a "server html generator", you can generate html with javascript on build time or with SSR live on runtime.
  • When it comes to client side front end, and if it deviates from static html, you might want to add some UI islands, but I think you're more focus on backend.
  • I did use a project with express.js for authentication and Astro as SSG handler https://astro.build/themes/details/astro-big-doc/, but that was long ago, now Astro has middleware so could handle auth.
  • Astro would not be capable of doing everything, if we think of a search engine for example, or any other backend heavy lifting, you might have a bench of custom services, but then from the client perspective, you will run in conceptual issues if you start fetching all sort of urls with your js client, so in one example, what I did is an express proxy so that the client keep using the same url (example https://github.com/VectorWisdom/typesense-test/blob/9a2e90155dbd12413648748097847ff0e5f3a06f/server/typesense_router.js#L40)
    So, I see Astro as the "Front-End" of "Back-End" so to say, the main advantage I see personally is to have a better grouping of server node.js code, which helps you with server logic + html generation within the same file.
finite galleon
#

Well, like I said im pretty new to Astro, so I might have missed some features here and there. I will try my best to put my felling towards backend in AstroJS into words:

  • I went through the Docs on the endpoints and anything related to the backend and I didnt find much things so that would be the first point. There is also not that much third party online resources since Astro is quite new especially Astro 3.0 compared to other "well established" frameworks like react.
  • On top of the few docs I have found, I have a very big dislike against JavaScript and honestly TypeScript is just not really that much of an improvement. In Java every IDE is able to show you very precisely what a class offers combined with JavaDoc's explanations. Im missing that in JS/TS, everytime I have to code something in JS/TS it just feels messy and undeterministic.

I know that the second point is hard to address for a JS Framework but it's something that really bothers me, so yea. I hope I was able to convey my thoughts. @lapis olive

lapis olive
#

All of these are very fair thoughts. I might have a biased opinion against java, I jumped from C,C++ to python and js, but if you're happy with ts, you should be with .astro as it is a wrapper on top of .ts
The reason you might not find detailed docs about Astro as backend, is that Astro does not intend to reinvent the wheel. So everything that you know from node.js and .ts is applicable. The ssr is another story, also not specific to Astro but limitations come from serverless runtime environments.
So in an api endpoint, or within Astro fron matter section, or inside a script tag, you can forget that we're taking about Astro altogether and use vanilla tooling and libs, either server side node.js or client side.
That being said, all the Astro black magic ususally relates to routing from fs or bundling, again there if you know Vite, you will know how Astro works behind the scene.
Impressions of newcommers to the platform is very important, the best you can do before starting to write code, is to see what the others are doing (after you've read all the doc) you can explore the source code of themes for example https://astro.build/themes/
If you share your experience in the future with concrete examples of what worked well or less good, that might also make a nice post topic.

finite galleon
#

Thank you for your answer. If I had to summarize my own issue with astro in this context, I think it would boil down to the fact that im not that very well into the JS Framework world. Someone (someone like you maybe), who is familiar with all these things in general wouldnt have these thoughts. I think its probably just that. The fact that im a noob to this but astro expects intermediate level @lapis olive

fading kettle
#

You can use express/nest/whatever and hook astro in for pages... using a single language make dev faster
Not sure what you mean about js not being deterministic or not having ide support... at this point ts has better ide tooling than java and doc comments are supported by every ide that I'm aware of

lapis olive
fading kettle
finite galleon
# fading kettle You can use express/nest/whatever and hook astro in for pages... using a single ...

i dont agree, but i might be just ignorant. My experience of writing Java in eclipse vs js or ts in vscode are in no shape comparable. Eclipse is made by java developers for java developers in java. while in vscode I find the auto complete for js/ts to be utter garbage (yes, i have the microsoft extensions for typescript ). Im sure if i would invest couple hours configuring something i would be better off at the end but i honestly dont want to spend the time

fading kettle
#

But also, its not apples to apples, that would be vs to eclipse

finite galleon
#

Autocomplete works, it’s just trash imo. And I said js/ts feels un-deterministic from my experience. And yes I agree that eclipse to vscode comparison is not apples to apples, I mentioned it to make my background a bit more clear

fading kettle
#

I don't know how something can feel deterministic 😄 it either is or isn't
Not saying you have to like js, but thats simply not true 🤷

frank moth
#

You definitely can use a separate backend server and integrate it into your Astro project and do the classic backend front end, basically just have anything you want to interact with Astro expose a REST API the same way express does

#

I imagine typescript tooling would grow on you over time too if you wanted to try it out I bet you wouldn’t regret it

drifting bone
#

for JS/TS I recommend WebStorm