Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

schneider.dev

Post reply on HN
Print view View original

141–150 of 155 posts

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#141

Post by amatecha »

ngngngng wrote: post #74
hliyan wrote: post #69

Great article. One point though (not aimed at the author). The majority of engineering articles I see today are along the lines of "X with Y, using Z", where X, Y, Z are specific products, frameworks or libraries, often trademarks. I rarely see more generic engineering/architecture topics such as: [virtual DOM based / string based client side templating] with [JSON/Protobuf] over [REST/Websocket] with a [compiled / i…

I'm actually writing a tutorial series aimed at programming beginners where we implement things in multiple languages/frameworks side by side. I think it's a great way to learn concepts of software engineering instead of just memorizing conventions.

Yeah this actually sounds awesome, do you have anything live/bookmark-able yet?

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#142

Post by ngngngng »

amatecha wrote: post #141
ngngngng wrote: post #74

Earlier quoted context omitted.

I'm actually writing a tutorial series aimed at programming beginners where we implement things in multiple languages/frameworks side by side. I think it's a great way to learn concepts of software engineering instead of just memorizing conventions.

Yeah this actually sounds awesome, do you have anything live/bookmark-able yet?

I have the first few lessons 90% completed but not published yet. You can bookmark my personal site natemeye.rs since they will initially be posted there before I move them to their own location.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#143

Post by quickthrower2 »

lame88 wrote: post #139
quickthrower2 wrote: post #52

Earlier quoted context omitted.

Haskell is a funny beast because I get a lot of joy from “conquering” the next level up (like a game) but in terms of productivity I’m not getting a lot done. OTOH in more pedestrian languages I’m using that brain BHP on getting stuff done. I really got into the Haskell thing a while back, going to meetups etc. but getting a job using Haskell is hard unless you’ve got experience already and want to take a pay cut.

Agreed - it certainly is rewarding in itself to get to the next level, but that's precisely it: the means become ends in themselves. I stopped using stuff like Arch Linux a while back for similar reasons.

Yep. Tools like Docker and Kubernetes on the other hand, I have found they give you a nice amount of leverage for much easier to understand concepts. In a similar "Workhorse" category I would put Git and Typescript. All of these require some effort to get to know, but they pay off nicely in terms of productivity.

Haskell is a pretty decent general purpose programming language, and if used well you can produce nice programs, but the problem is that the library you need will use some clever type system stuff and suddenly you are spending hours trying to understand how it all works.

For example I'd be happy doing a lot of stuff in the IO monad with some pure bits to the side where needed. Avoid the free monads, monad transformers, type classes and all that jazz. So use it like an imperative language for the most part.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#144

Post by kukabynd »

pmontra wrote: post #82
xlii wrote: post #78

Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it. Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution. For example, simple task of adding new entity consists off: On backend: creating migration, creating data entity (Ecto), writing structure module (sanitization, validation, basic logic,…

Similar experience but without GraphQL. We had server side rendering with a Node server. Our production server became a Node farm with Phoenix + PostgreSQL requiring less than 1 GB of RAM and Node using at least 8 extra GBs. We eventually ditched SSR, send the React app and wait for it to render. We're back to 1 core and (mostly unused) 4 GB. It's a business application with complicated UI, customers don't mind waiti…

What load did you have? Was SSR used in private routes as well?

In my experience, SSR should not introduce more complexity than you already have.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#145

Post by mercer »

beckler wrote: post #128
kuon wrote: post #88

I just started a new app, and I decided to try Phoenix LiveView. It's really simpler and easier to work with. It won't work well with all kind of apps, especially those with offline support, but for many many apps/website it is a good fit. The last app I did was a mobile app written in Elm with Phoenix. I can't recommend Elm enough, it makes JS much easier to work with. For communication I used a simple REST oriented…

I want to like Elm, but every time I try to pick it up it's always my biggest time sink.

Could you elaborate? I'm on the fence about Elm mostly because of 'ecosystem issues' (single dev, various complaints about communication, etc.), but more than once I've almost started a project because I figured the practical benefits would still be worth it.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#146

Post by mercer »

hliyan wrote: post #69

Great article. One point though (not aimed at the author). The majority of engineering articles I see today are along the lines of "X with Y, using Z", where X, Y, Z are specific products, frameworks or libraries, often trademarks. I rarely see more generic engineering/architecture topics such as: [virtual DOM based / string based client side templating] with [JSON/Protobuf] over [REST/Websocket] with a [compiled / i…

I agree, and I've been itching to write an article that is a bit like the 'generic' approach you describe. But I'd have to start a blog first :-/.

For many web developers, front-end, full-stack or otherwise, perhaps it's usually clear enough what the underlying approach of a particular framework is. But I imagine people who don't read up on the latest developments especially it might be helpful to get an idea of the underlying fundamentals of particular stacks/frameworks.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#147

Post by mercer »

namelosw wrote: post #47
sugarpile wrote: post #29

Does anyone here who is working with elixir professionally have a sense of what kind of mastery is needed to jump into an elixir dev role? I've used it on and off for ~4 years at this point and in a few side projects (most recent one using everything in the title, weirdly enough) but can't really tell if I'm "qualified" to look for a job in it. It's this weird loop of "I've only done something as a hobby so I'm not q…

I think for Phoenix it's quite easy to deal with unless the project requires a lot of Erlang/OTP stuff. If it's just plain old request/response styles website (I think most of the project falls into this bucket) if you can handle other frameworks like Rails or Python, you can handle the same thing really well after some usage. Some basic knowledge of the language/MVC/Ecto would do. Though there are a lot of React dev…

I do find that I feel a weird kind of 'tension' as an Elixir programmer where on the one hand I think I'm pretty proficient with Phoenix and Elixir's syntax, conventions, and ecosystem, but way out of my depth when it comes to OTP, distributed systems, and so on.

It almost feels like these are two completely distinct worlds, but because they're part of the same language and community, it's difficult to feel proficient or even 'adequate' at times.

I never quite felt this way as a PHP/Ruby/JavaScript developer, as for the most part the challenge seemed to be knowing the right frameworks, new language features, or bundler/build tools to be 'good'.

In the most recent episode of Elixir Outlaws, the topic of overusing OTP/processes/Agents is discussed (https://elixiroutlaws.com/37), and it made me feel a bit better about my lack of experience in this area (and much as the podcast can be on the 'whiny' side of things, it's probably my favorite Elixir-focused one and I highly recommend it! If you're reading this: Hi Chris, Amos and Anna. being a friend of the show one day is on my bucket list :).)

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#148

Post by mercer »

thegabez wrote: post #7
em_jones wrote: post #2

I've just been trying to get back into elixir recently, myself. I'd done some basic crud 'helloworld' stuff when I first tried about a year into professional development. I've since had the Fortune to spend time learning about cloud native apps, distributed service patterns, and supporting infrastructure (spring cloud, pcf, vanilla k8s, gcp) and now returning to elixir having at least better understanding of what erl…

I liked this "Elixir For Programmers" by Dave Thomas https://codestool.coding-gnome.com/courses/elixir-for-progra...

I can recommend this one too! It skips right over the boring stuff and focuses on the (Dave-Thomas-flavored-) good parts. Definitely worth it if you're already somewhat proficient in Elixir.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#149

Post by fnky »

jypepin wrote: post #90
dafrie wrote: post #86

Earlier quoted context omitted.

Just a quick one: why would you need redux for forms? This is in my opinion a total overkill. I have forms either having their own state or (preferred) just use Formik for all of this. In my stack, this then allows to just add a field in the GraphQL schema (backend), add it in the query, add the formik field + yup validation and done.

Some people would argue that if using Redux, also having local state logic is an anti pattern. That would mean that if you use Redux, a form also requires actions for form update/submit/success/error and the form data should be stored in the redux store. That is one of the main issues I have with Redux, which I feel adds automatic complexity for simple things, but at the same time I'm not sure if it's very good to ha…

I don't see how you can blame something for adding complexity based on what other people _think_ is an anti-pattern.

In fact, it's most of the times not desired to update your store before you know the data has been validated anyway. The store should always be the source of truth, but that also means that it should be valid.

That's the approach I am going with in any case when working with some kind of global state.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#150

Post by fnky »

xlii wrote: post #78

Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it. Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution. For example, simple task of adding new entity consists off: On backend: creating migration, creating data entity (Ecto), writing structure module (sanitization, validation, basic logic,…

Most of the things I've seen people complain about being complex seems to be a lack of either understanding, proper tooling and in most times, the codebase itself.

Newer technology usually adds a ton of different patterns and abstractions that can hide a lot of things away from you, so it becomes hard to understand, unless this information is presented as a 101, or you invest all your time to read documentation about each individual part of everything. Which, to be frank, nobody has time for.

I have used GraphQL with Apollo and React for the last couple of years for different kinds of projects and what I have noticed is that the tools themselves, while quite abstracted, also try to support a lot of edge cases which can make it hard to apply to your project. I had to either use other libraries or build my own that helped me abstract some of the things that were most commonplace but required a lot of boilerplate otherwise.

I have found tremendous value by following the philosophy of not to pre-optimize for everything, until it becomes a burden to work with. Although, it can be hard to determine when something is going to become so big that it will be difficult if not impossible to refactor, but you learn that as you go.

Post reply on HN