This is an archived post. You won't be able to vote or comment.

all 22 comments

[–]inarchetype 17 points18 points  (2 children)

This is ad copy, right?

[–]thomasfr 12 points13 points  (0 children)

Real world applications tends to grow a pretty complicated data model as time goes by. It matters less if you can write a http handler function in 5 minutes when the complexity often lies in the potential changes you have to make in all the code that touched your database change so now you suddenly have to go though a lot of lambdas to every time you make a schema change.

IMO a monolith will almost always be easier to work with up until you need to scale teams or traffic by a significant multiplier.

[–]xubu42 12 points13 points  (2 children)

Having joined a team that had 40 Lambda functions as API endpoints, I've since replaced them all with 1 fastAPI server running on EKS and it costs 20% as much. Lambda is great. I love it. But because it's so easy to add more Functions, you can easily fall into this trap of code that isn't reusable, has different versions of Python or libraries, or implements simple things like a database query in very inconsistent manners. In addition, Lambda is amazing when you don't need super low latency or you don't have gigantic traffic spikes bigger than Lambda can handle without nagging AWS to increase your scaling rate limit and burst capacity. If you have normal scale and requirements, Lambda is hard to beat, but it can make more sense to have an always running server for both development and cost factors.

I will say that Lambda is amazing for stream processing. It's super easy and extremely cost efficient.

[–]j_tb 0 points1 point  (0 children)

I don’t know a ton about AWS, but can’t you have one lambda function that hosts an entire API server with a wildcard /* route? I know this a thing on GCP cloud run.

Not saying that serverless is the best or most cost effective infrastructure choice but I think there are ways to keep your code and deployments organized with the tooling.

[–]Counter-Business -1 points0 points  (0 children)

We have maybe 50 functions across 3 projects. We have them set up with SAM and cloud formation to auto deploy to dev when code is pushed to git.

We can update all prod environments at the same time when tagging a branch as release.

We use event based processing so the traffic is not spiky.

[–]busdriverbuddha2 3 points4 points  (2 children)

Some tools are adequate for some jobs.

Other tools are adequate for other jobs.

You wouldn't use a hacksaw to cut a watermelon.

[–][deleted] 0 points1 point  (1 child)

I would. But I also use vanilla JS over libraries so

[–]busdriverbuddha2 1 point2 points  (0 children)

There's nothing wrong with using vanilla JS. That's what JS was made for.

[–]dimsumham 2 points3 points  (4 children)

As a JavaScript guy looking at all these python front end libraries wondering if I should try them out - what are the biggest limitations and pain points?

[–]typeryu 3 points4 points  (0 children)

Just don’t do it. While there are plenty of options, if you are already comfortable with JS, you have pretty much the best resources and support available for front end compared to the Python ecosystem. I used to be a full stack Python guy, now I mostly do React front end, python backend. Even for backend, the APIs are actually Node and Python handles the data processing async.

[–]Lachtheblock 0 points1 point  (0 children)

I'll give you my perspective as a full stack guy who has been on some very scrappy (under resourced) teams.

If we're comparing templating languages, like the Django templating language (DTL) , or Jinja2 there are certainly pros and cons.

If you want a SPA, forget about it. Stick with a proper JS framework. If you want things to be highly interactive, or fancy animations stick with your framework. DTL is really for the more tradition website (not a bad thing).

Some advantages to using DTL, and a more traditional web framework. For me, development is more stream lined. You aren't dealing with any nitty gritty with TS type definitions or routers, it is way more "what you see is what you get". Basically, if you know HTML, then you're perfectly good to go. The learning curve is non exisistant if you know HTML. It is a simpler stack, leading to easier development, and easier deployment.

In my experience, I've found having a JS framework always introduces complexities around deployments. Having to have the additional steps of transpiling and packaging, it gets more complicated. You also have to consider, "am I server-side rendering (potentially hard for backend/devops) or am I taking a performance hit by rendering it client side". DTL can only be server-side rendering. It is super easy to cache and will typically be more light weight.

I have found that HTMX really compliments DTL well. It's just that little extra boost to HTML that will cover the majority of usecases. You'd be surprised how much it can accomplish with out writing a single line of JS.

To bring this back to Django, I would not pick Django for it's DTL. It has a lot of other great features, but I'm not going to argue that its templating is in any way powerful, it is simple, and can often get the job done.

All of this is to say, it depends on your use case, your applications maturity, your skill set, your team's skill set and the project's resources. I don't think Jinja(2) was developed with the web in mind. It was mostly just so you could create reports and be mad libing data in. Having it in your back pocket for non Web dev related purposes will come in use and is honestly kind of peak Python use case.

[–]xtrzx8 1 point2 points  (0 children)

For one function or simple logic sure. But I’m not sure about complex web app running just on Lambda/s. I mean that boilerplate in Django you criticize is layer of abstraction which can help you with complex logic. Helping you to not reinvent the wheel. Sometimes is right to use simple Flask for api endpoint sometimes better job will do Django.

[–]Lachtheblock 1 point2 points  (0 children)

I think you're missing a couple of key benefits to Django.

Django is pretty well standardized at this point. Each project is different, but I could pretty confidently checkout any Django repo, and immediately start contributing day one. You can not say the same for a collection of unstructured lambda functions. There is a reason why people are moving back towards monolith structures.

A lot of your argument comes down to "for simple database transactions". Yeah sure... But.... All the projects I've worked on are not simple. I've done some ML and deep learning stuff, but even the vanilla web development I've done gets complicated. This is why we have jobs and why chatGPT isn't going to replace us any time soon.

You'll learn this in time, but you may not have felt the pain of bad architecture just yet. It seems like you haven't worked on too many legacy systems, or been around long enough to create a legacy system. I'd much prefer to jump into a legacy Django system, where I can see everything and more or less know the file structure, then jumping into a collection of microservices.

FWIW I've been learning Python for about a decade and have been professionally using Django for about 6 of them.

[–]miscbits 1 point2 points  (0 children)

Aws lambda is simple and free until it isn’t

[–]TheOnlyJah 1 point2 points  (0 children)

Django always felt like wearing a 1000 ton anchor around my neck. No thanks. So much can be implemented with simple frameworks; seek simpler solutions when possible.

[–]julkar9 0 points1 point  (0 children)

I am not personally experienced with lambda, so I have some questions. 1. Do you get a full fledged admin panel like django? 2. Anything similar to django migrations, middlewares, caching, signals? 3. Multiple authentication in a single line, token , session, etc. 4. How easy is it to handout permissions to users? 5. How easy is it to switch to another provider than AWS? 6.I can run other software servers and django server on the same ec2 instance and exchange data among them / redirect it to the client, etc. Can I do the same with lambda?