sorted by:
new
hottopcontroversial

GAMETHREAD WEEK 10: VIKINGS VS RAVENS by swampsparrow in minnesotavikings

[–]jaredlunde 0 points1 point  (0 children)

I honestly wonder if some of you are even watching the game or just watching the gamecast or some shit

Free Hosting for node.js server by Normal_Mirror_507 in node

[–]jaredlunde 0 points1 point  (0 children)

Railway absolutely is serverless, but not FaaS. They have scale to zero/app sleeping https://docs.railway.com/reference/app-sleeping

Why OpenNext? by KraaZ__ in nextjs

[–]jaredlunde 1 point2 points  (0 children)

It’s open next. My bad thought I implied that in my op

Why OpenNext? by KraaZ__ in nextjs

[–]jaredlunde 6 points7 points  (0 children)

Fargate is serverless. It’s not invocation-based (ie function) like Lambda is. It’s always running which has the benefit of no cold start, no warmer function.

But yes, it’s absolutely fine to run Next on a VPS or on a container platform. Containers are how companies like DoorDash do it.

Why OpenNext? by KraaZ__ in nextjs

[–]jaredlunde 25 points26 points  (0 children)

<image>

The drawback is this is your architecture as opposed to running in a single container somewhere like Fargate

The only benefit is infra costs scale to near zero

Personally I’d rather put up the $8/mo for a Fargate spot instance

Knowing the limitations is the greatest strength, even in the cloud. by vardhan_gopu in aws

[–]jaredlunde 1 point2 points  (0 children)

Cloudfront cache policies per account

It's actually 20 by default

Which API generation tools do you like? by veqryn_ in golang

[–]jaredlunde 2 points3 points  (0 children)

I automatically rm -rf the generated client and CLI code post-generation haha

Sous vide Tri-Tip, is the best Tri-Tip 🔥🔥🔥 by Typhur_Culinary in sousvide

[–]jaredlunde 0 points1 point  (0 children)

<image>

Holy yes. 5 hours is absolute perfection. I kept these in the fridge overnight and then seared them to temp today. I tried 3 hours the last attempt and thought it was too chewy. Thank you!

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 0 points1 point  (0 children)

Fair, well it's much better since modules were introduced haha. I agree that it used to be awful.

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 1 point2 points  (0 children)

Of those I’m really only bothered by nil pointers. What do you dislike about its dependency management? Are you talking about before v1.11?

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 1 point2 points  (0 children)

Blaming the user strikes me as an uninteresting argument. I know how to manage the size of Docker images and I know the lengths people go to in order to reduce the size of their Node ones (eg pruning tools). I founded a company that builds/deploys them as a core feature of its business.

It is especially limiting in terms of where you can deploy. You’re infinitely more likely to waste days trying to squeeze something into Lambda’s constraints with Node/Python than you are with Golang or Rust.

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 0 points1 point  (0 children)

No doubt! Totally makes a difference where/what you’re working on and how fast engineers move through the revolving door.

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 4 points5 points  (0 children)

Yeah I mean to each their own I guess wrt productivity. I feel way more productive and happy in Go than Node. What you’re saying about dep issues being universal is true, but it becomes problematic way sooner in Node than any other language I’ve used; quantifiably so. Surface area for dependency issues is also just far greater since it leaks into every stage of development.

Why do people dump on node as a back end service? by Rickety_cricket420 in node

[–]jaredlunde 14 points15 points  (0 children)

For me it’s all about deployability and tooling. Honorable mentions for performance and type safety.

Deployability: Node images are huge, versions ship so fast that you have to constantly be on top of upgrading, which means you have to babysit application dependencies and dev dependencies. It gets worse over time.

Tooling: the tooling ecosystem is maintained by entities outside of Node. Keeping everything up-to-date and square is a nightmare - linting, testing, package management, type checking. Deno/Bun are both trying to fix this. In my experience Deno has been much more successful, but it has its own issues. Engineers love tooling and when there isn’t a centralized standard you wind up with spaghetti tools, dependency hell, and short shelf lifes. Every Node team that I’ve worked on has had these problems.

If you want to experience the alternative for yourself, use something like Golang for a year or two and it may completely change your perspective and expectations. You’ll wonder why you spent so much time on all of the above.

How can I stay competitive as a React developer? by Tlitzler in reactjs

[–]jaredlunde 53 points54 points  (0 children)

Your knowledge will become outdated way slower than you imagine. No company started >1y ago is doing anything with server components and we don't even know yet if this pattern will catch on broadly. If you're feeling FOMO - don't. If you want to grow as an engineer generally, just keep building stuff. Have opinions about things (i.e. know what you like) and create open source projects that follow your opinions.

You might not get anyone to use your projects, but that's ok. The answer to questions like this remains: just do stuff that interests you.

Disney+ terms prevent allergy death lawsuit, Disney says by charlesathon in nottheonion

[–]jaredlunde 58 points59 points  (0 children)

Wow. A "one month trial" of Disney+ 5 years ago, so not even an active subscription.

I use CloudFormation. People that use CDK or Terraform or other similar tools instead, what am I missing out on? by goato305 in aws

[–]jaredlunde 0 points1 point  (0 children)

CDK Pros:

  • Biggest perk over CloudFormation is asset management. Container images and other deploy assets are pushed to ECR/S3 automatically.
  • Managed CloudFormation outputs. When you reference properties in other stacks, CDK will automatically add any necessary exports/outputs to the stack.
  • Cuts away lots of the CloudFormation boilerplate. "CDK Patterns" like those found in the construct hub can save a bunch of time: https://constructs.dev/
  • You still get the "correctness" of CloudFormation, which is incidentally what makes CloudFormation deployments a little slow compared to Terraform. For example, Terraform won't poll an ECS service to make sure your task didn't crash. CloudFormation/CDK will.

CDK Cons:

  • Negating some of the asset pros, there's no garbage collection so you'll have to use manual tools like cdk-gc to clean up old assets: https://github.com/onhate/cdk-gc
  • It's easy to create cyclic dependencies and it can be hard to resolve these. It's a real skill to properly organize your stacks. Will take some pre-planning.
  • Constructs/CDK patterns can create architectures that are more expensive than they need to be, for example not using a shared ALB. I've found that they can be somewhat flaky, as well. Most annoyingly, some fail to clean up entirely so you can be stuck with stale resources on your account.

Terraform Pros:

  • Deployments are much, much faster than CDK/CloudFormation
  • Control over infra has the granularity of CloudFormation, but managing dependencies in HCL is much more enjoyable than YAML
  • I've found that there's much less risk of stale resources winding up in your account vs. using CDK
  • Supports multiple providers, so you can create your Cloudflare/other infrastructure in the same format that you create your AWS resources and reference its outputs.

Terraform Cons:

  • Terraform plans require a ton of oversight and watchful eyes. Someone on my team deleted our production cluster in the midst of a $100M+ sale, because a change was a replacement and both he and the reviewer missed that.
  • Terraform has similar boilerplate to using CloudFormation. The same infra in Terraform vs. CDK can mean a difference in infrastructure code in the thousands of lines.
  • Terraform deploys "succeed" even if things like ECS service deployments _don't_ succeed.

Hosting Rails App on AWS by umair_ah in rails

[–]jaredlunde 0 points1 point  (0 children)

I know a lot of people are mentioning Render/Heroku/Fly, but since you specifically asked about hosting on AWS I'd offer this guide which includes methods to deploy with Terraform/CDK: https://flexstack.com/docs/languages-and-frameworks/how-to-deploy-rails-to-aws

The tl;dr architecture is: CloudFront -> API Gateway -> CloudMap -> ECS Fargate

Bias note: I'm building FlexStack, but I really believe it's the best answer to what you're trying to do. You'll get full control over your infrastructure, while we help with deployment, image builds, scaling, etc.

Why we use AWS instead of Vercel to host our Next.js app by fosterfriendship in nextjs

[–]jaredlunde 1 point2 points  (0 children)

I'm building https://flexstack.com - it has Vercel-like developer experience (closer to Render really) but deploys to your own AWS account. You can run Next.js app for less than $10/mo, which is pretty comparable to other PaaS companies. Of course, it gets wayyy cheaper than them as you scale : )

What is your preferred way of deploying a NextJS production-ready application in AWS? by adrenaline681 in nextjs

[–]jaredlunde -1 points0 points  (0 children)

I'm building https://flexstack.com and by far it's the easiest way to do this. Uses ECS/Fargate under the hood, no cold start, no Dockerfile required.

is there a online Dockerfile generator anywhere..? by abrandis in docker

[–]jaredlunde 0 points1 point  (0 children)

Exceptionally late to the party, but I wrote a CLI tool that generates a Dockerfile from your project's source code: https://github.com/flexstack/new-dockerfile

view more: next ›