Contexts - a barrier too high for newbies?

It’s not unfair to ask folks, newcomers included, to at the very least use Phoenix before etching their stance in the ground. This doesn’t mean I expect folks to learn everything, by “use” I mean at the very least I think it’s fair to ask someone to go through the getting started guides and tinker a bit before coming here and piling on with negative feedback.

That is not at all what I’m suggesting. The post in question said they hadn’t even taken a look at Phoenix yet.

I always appreciate newcomer stances, since after all I’ve been helping to grow the community since the beginning. We are by definition community of newcomers right now :slight_smile: I’m only asking that folks who want to take a negative stance here at least have run mix phx.new before. I don’t think asking such is unfair.

3 Likes

Fair enough Chris. It is what he said. I did not take it as literally or he would not even have been here discussing contexts. I do think a lot of people read through docs before they decide to actually create a project. Then they weigh the complexity they see against the utility. Anyway I have fired up a few projects and I would have done the project I am now doing in Django with Phoenix except as a newbie I thought it would be a very bad idea for me to roll my own authentication or even think i had expertise to know which existing one was secure enough.

I guess for contexts to totally click for me I would have to see a project in a previous version compared against the latest version of phoenix with code to really see the overall benefit it is to me in my stage of development. I am at the dangerous point of thinking I get it but not sure what I got is right :slight_smile: . I’ll keep looking and reading.

This is exactly my main pain point with Phoenix. Although I use it I feel very insecure with authentication because I’ve used all the approaches:

  1. make my own following the Phoenix book (to learn and use it in a very simple use case);
  2. use Coherence/Openmaize/Phaux but none of them is stable or covers my needs (Oauth);
  3. looked into Guardian/Ueberauth but I don’t want to use JWT (I want to leverage Phoenix tokens).

So, authentication COULD BE the thing to make me leave Phoenix as IT IS the thing that keeps me periodically testing other languages/Frameworks hopping that there’s a new one as good as Phoenix but with Authentication.

1 Like

It’s nor unfair indeed, but in the competition for user mindshare, it might lose future hsers to other applications that do not require that. We have an embarassment of riches in the web framework department. I’ve only used python frameworks and some JVM based ones. Python alone gives you Django, Flask, Pyramid, Websauna (on top of pyramid), aiohttp, sanic, falcon, CherryPy, Tornado, Twist. The JVM gives you several languages, each with one or more frameworks, like java (Spring, Spark, too many others to list), clojure (Luminus, noir, but it’s mostly DYI based on something like plug), scala (Play, Scalatra, Liftweb), kotlin, etc. This doesn’t even touch frameworks written for C, C++, go, javascript, ruby or many others.

Most of these frameworks are quite similar to each other (i.e, they consume requests and spits responses – booooooring, that’s so '00s!), but they all create noise. At the same time, some are obviously better than others for some uses, even within their sometimes limited capabilities.

A newbie doesn’t have time to run framework.new for every framework out there. This is not a value judgement, it’s just a fact of life. I’ve done it for most python frameworks, but I can’t do it for all frameworks out there. So frameworks must have some way to convince users to try it. For me, it was @chrismccord’s video in the phoenix’s website here. But the video is not thaaat convincing in general for a newbie. It convinced ME because I had a prototype of a web application I couldn’t make work with anything else the way I wanted it. But newbies often want to learn a tool to build something, to get “something” out there. And that video is not convincing for those use cases. I do believe that phoenix is the best tool for almost any web application, unless some other language already has something prebuilt that is just perfect for your project (libraries, frameworks, etc). But nothing in the docs/forums or videos would convince me of that.

To capture newbies, Phoenix must sometimes say: Phoenix is your application! Dump stuff into the controller! Request comes in, response comes out! Web apps are interfaces to a database! 90% of all web apps are CRUD and phoenix is very good with CRUD! Phoenix is Rails + websockets! Even if these are all either bold faced lies or very stupid marketing points.

This is what gets you newbies, not 9 nines of reliability, not code swapping, not references to boring european Telecom companies. I mean, these things totally got me, but I’m not thaaat newbie.

Now, it’s totally OK if you don’t want to get very green newbies, or if you don’t want to get them hard enough to use my sentences above as marketing points. Some users in this or other threads have actually said that too many newbies is not necessary a good thing. But to be really appealing to newbies, Phoenix reeaaaly needs to up its marketing game.

Another problem is the fact that many inexperienced people seem to be jumping to a release candidate that doesn’t even have a proper tutorial that holds your hand through an entire application.

But in any case, I think some concrete steps might help newbies and even some more experiences users that are struggling with contexts.

What might help newbies

First, from the point of view of the general documentation:

Django has the django tutorial. Flask has Miguel’s mega tutorial. Pyramid has the official docs and multiple tutorials. They all walk you through an example application, through which you can get a feeling for how an app is structured and why things are the way they are. Phoenix has some docs for 1.2 that are as good as the ones I’ve linked, but nothing that deals with contexts…

Newbies NEED and example of an application using 2 or more contexts with real boundaries, in a way that makes sense, even if it is a small application or almost a toy. As long as it’s real code it’s good enough. We don’t have anything like this yet, and we should. This is something I’d like to do, but for which I unfortunately have no time right now.

This is even more important if Phoenix wants to capture newbies that are learning Elixir as their first backend app (well, second if you count JS as a “backend app”). I came to phoenix already knowing what DB abstraction layers, models, routes were. Each of this things is a stumbling block. Functional programming (which is much simpler to me than any of the alternatives actually), processes, OTP (even if you can do stuff without knowing what this is) and Supervisors. Now, add the 3-4 levels deep abstraction (as I explain below) of contexts, and you might get the:

Second, from the point of view of context generators:

I think contexts are a very good thing. They are a nice way of organizing the code and very useful even for relatively small apps. But they are also a little abstract. In the end, a schema is a subset of DB columns, and a context is a set of schemas. If you think like this, you can actually draw some pretty Ven diagrams or some pretty tri-partite graphs. But a command line interface is not a very good interface to something that draws tri-partite graphs.

A way of visualizing DB tables, schemas and contexts graphically would be very helpful for some visual thinkers like me. Double so if you could actually plan and generate your contexts/schemas/migrations through a visual interface. The stack from contexts to DB tables is 3 levels deep (and 3 files away!). Also, migrations are “deltas” of tables, so you can count that as a 4th level.

3 Likes

alright then I may be close. Could you say that since in some frameworks you devise your schema from your model that contexts are more discrete/specified models that divide/hones in on the separate concerns? lol if thats not even close then I have a LOT more reading to do.

[quote][quote=“PJextra, post:121, topic:5929”]
2) use Coherence/Openmaize/Phaux but none of them is stable or covers my needs (Oauth);
[/quote]

I hope thats not true. Contexts might turn out not to be a barrier too high but asking newbies to choose among unstable packages (and I had thought by now one of those would be) or roll their own definitely is not newbie friendly. the community should at least have a vetted recommended and stable package.

Have you seen this thread:

Try this post first.

There are a number of threads about built in auth.

yes I did and I purposefully didn’t want to mention it because I felt some might take offense but some of those explanations are exactly why Phoenix is now coming across as not newbie friendly. its kind of what I meant when I wrote
“high minded conceptualizations sentences without much specified meaning”

D o not wish to offend but sentences like these have no concrete meaning -

the last one isn’t that bad except whats being referred to as a web layer is quite ambiguous. you could use that language of a view.

There are a few posts in that thread that did in fact shed some light when I first read it but also quite a few that would scare the beejeezuz out of a newbie as reading some Microsoft docs would.

1 Like

No, it’s much simpler than that. Contexts don’t actually exist in the same way that schemas do xD A schema is a real “object” (I think it’s a struct or something, I actually don’t know much about ecto yet) defined using a specific macro. A context is simply a module where you dump some functions related to schemas :slight_smile: In this way to gather related schemas.

Is it clearer now?

Haha yes, some are much more in-depth that I imagined would be posted. However, for a total nube, I think the initial description should put their mind at rest:

Phoenix Contexts are just dedicated modules for functionality that can easily be classified as a group.

I am sure that once the Phoenix book and guides are updated it will make much more sense :slight_smile: (and if it doesn’t, I am certain the team and the rest of the community will work to make it so).

not even remotely…perhaps if someone could show what kind of functions you are talking thats in relation to a schema the light bulb may come on. What I thought was the best examples talked about accounts , users etc in a way that you would break up a traditional model so like I said if thats not even close then I’d have to start all over again.

again though if there was some real code to look at it would help tremendously… I don;t think many people will be coming to phoenix and elixir as their very first programming experience so unless this is something entirely new to the programming world comparing it to some pattern or approach out there would be most beneficial as well. Perhaps I am dense but its only in regard to phoenix. I have had no such problems picking up any other framework’s concepts (but of course almost all of them are replete with code examples).

…but but…:slight_smile: I was including that line. It might not be confusing but its entirely meaningless. No newbie reading it is going to say aha …after reading that I get what it is and why they should use it. Frankly I am sure it doesn’t say anything practical even to a seasoned programmer in another language and framework

hopefully but (and I see this a lot with phoenix subjects) if you have to buy one book to begin to understand a modern web framework its not a modern web framework. People expect in today’s language market that they can make sense of it through online resources. Always should have good books and if you are serious about a framework one written by the author of a framework SHOULD be on your shelf or tablet but the often given answer - get the book - is not something anyone is going to do that is not already committed to learning it. When that happens you are essentially asking people to literally buy into what they haven’t bought into.

and thats fine if as the OP said you want the framework to be niche focused to non-newbie developers.

I think this is the main point. People don’t want to be “behind” so they hop on the latest version no matter if it’s stable or not. The fact that there are no 1.3 tutorials is more-or-less the same as if there were not tutorials at all. I’m pretty sure it’s not the word “context” that is scaring - coming to Elixir/Phoenix you hear a lot of new words - processes, supervisors, pure functions, and more - what is scaring is that this particular new word is not mentioned in the docs or guides. I feel like for the last half a year Phoenix was in this kind of limbo of everybody waiting for the next thing, not exactly sure what to do.

This is not to assign blame or anything - I know how it is and that’s not the point. I would be glad to help if I knew how.

6 Likes

I’m reserving full and proper judgement for now as I am yet to learn Phoenix myself. (Tho the basic description seems to make sense to me.)

I think guides are great to get people going and to refer to when you’re building stuff, but if you want to properly learn something, I feel you should learn it via dedicated learning material - such as books and other professionally prepared and edited courses/material - I can’t stress this enough - I’ve seen so many people (in Ruby and Rails) just hobble along and get stuck on simple things, when just reading one book would advance their knowledge immeasurably. I feel this way about all tech/languages - but that’s just me and my preferred way of learning.

If you prefer to learn using guides, I’m sure the Elixir/Phoenix guides are just as good as if not better than most out there :slight_smile:

Then just use Ueberauth. It has no reliance on Guardian at all as they are two entirely distinct libraries that do two entirely different functions and you can use Phoenix Tokens just fine (I do). ^.^

By default, the generators add CRUD functions like create, delete, list, etc. IMO they don’t come with huge benefits (they are thin wrappers on top of the Repo functions). The idea is that you would add higher level functions there yourself like list_all_documents_for_user, which contains a complex Ecto query. This takes away the query from your controller, which keeps the controller smaller and more focused on the web stuff.

The oyher advantage of the contexts is to only deal with the DB columns you really need. You can have a Subscription.User (which contains only a billing address, a username and a reference to a payment in the ledger) and a Document.User (that contains only the user name, a reference to documents and no billing address because that part of the app doesn’t need it.

If you’re still confused about contexts, maybe you already know what they are (just modules!) and just don’t see the point of having them. That’s ok :wink: they are overkill for very simple apps, and add some non-trivial boilerplate. My advice is to just put everything in the same context untill you think you should do it differently.

1 Like

The importance of online guides is to show some code so that the user can get interested in learning further. They do not necessarily replace books. But personally I would never buy a book without looking at some high level online description with code examples - it kind of feels like a scam if the aithor of the book can’t convince me that the content of the book is worth it.

Phoenix’s website is very good (perfect even): it has a high level video, an tutorial in which you build an example app and pointers for other resources. I’m of course very interested, and will eventually buy a book by one of the authors. Still haven’t decided which one to buy first though :stuck_out_tongue:

Obviously, it doesn’t contain the docs for the release candidate (with contexts), but that’s why it’s a release candidate, and not a proper release…

I won’t belabor the point any further but thats not what I said - Both have their place and is not a matter of me preferring one over the other. Most people who buy a book are already committed to the subject not deciding if they want to be. In today’s world they come to that point by reading and watching online first.

You’re in the ecto core team, so there is at least one thing you can do: either confirm that a visual editor for contexts is a good idea or dash my hopes ahaha

I know it’s probably not a good idea because contexts are not a declarative enough concept (they include functions, and editing those with a visual editor is visual programming and therefore will fail as history has shown again and again), but an interactive schema editor that maps schemas to table columns and migrations to full tables would be feasible (through introspection of the relevant ecto structs). Am I right?

Also, you might start working on a demo open source app that uses 2 or more contexts. I can’t do it right now due to time constraints, but I might do it in the future :slight_smile:

Coherence is stable and quite feature rich. I’m using it right now. There should be a release coming soon with support for the new Phoenix folder structure. The only thing missing is an official way to integrate with Phoenix contexts. We’re discussing ideas.

I certainly don’t think that Phoenix fails here. I think that online guides on the official Elixir and Phoenix site are a pretty good start. In fact, even as a book author, I tell people to first start with the online guides for a quick start, and then move on to some book(s) if they decide to pursue the tech more seriously. The guides will give you a quick way to try out the tech in practice, and can even allow you to be productive very quickly. But for anything more involved, you’re going to need to research more material.

2 Likes