Open nelsonic opened 2 years ago
I'm working on this as I go along. I've already created the PR for https://github.com/dwyl/learn-flutter/issues/68 so that should tick that off.
I'm finishing the https://github.com/dwyl/flutter-counter-example/issues/5 issue as well. Currently re-writing the README so it's up-to-date and correctly formatted.
An update on this:
Most of the "before-the-roadmap" repos are done/waiting to be merged. I'm going to work on the Todo List Tutorial with Phoenix API
, which seems to be an enhanced version of what was done with https://github.com/dwyl/learn-flutter/pull/69.
https://github.com/dwyl/learn-flutter/issues/70 , as it was commented doesn't really make sense to exist because drift
was used in https://github.com/dwyl/flutter-stopwatch-tutorial/pull/2 and it can perfectly serve as an Hello World application of using drift
.
Most, if not all of these are awaiting approval to be merged so I can sort out the CI.
dart_cid
https://github.com/dwyl/dart_cid/pull/3 which is blocked by dart_multihash
https://github.com/dwyl/dart_multihash/pull/2 pending approval to merge.Wanting to get all of these sorted before passing on to the Roadmap
section.
@LuchoTurtle as discussed, we want to persist the items
in the Flutter
Todo List Tutorial to a REST API
that will be build into the Phoenix
Todo List Tutorial: https://github.com/dwyl/phoenix-todo-list-tutorial/issues/53 π
Please LMK if this is clear and if you need any help with any of this. π
Perhaps I'm getting ahead but I was looking at options for integrating Flutter with Phoenix and a few questions arose.
We are going to leverage Phoenix for its soft-realtime capabilities, so Flutter should be able to make use of Phoenix Channels. I've found two relevant options for this:
phoenix_wings
, which seems to be the de facto way of connecting to Phoenix's channels, albeit older and looks to not have been updated for 2 years.phoenix_socket
, which seems to be less popular but much more recent and with active support.I personally believe we should go for the latter but that's up for debate. As @nelsonic said, Phoenix Channels are WebSockets to the core. Using the native WebSockets package for Dart is an option but using these wrappers will be more time-efficient for us.
Phoenix will act as an API, as well. I've dabbled with the thought that adding GraphQL would be a sensible decision in the long term. But is it worth it for the MVP? Are we using a shotgun to kill a fly? I'm mentioning this because this topic was discussed in Elixir Forums - How to Integrate Flutter with Phoenix and Absinthe was mentioned from a user that was creating a Flutter App with it. GraphQL allows subscriptions, which work through Websockets. But using this seems to kind of negate using Phoenix's Channels, which is the bread and butter of the framework (also, Absinthe sockets is only available for JS clients, not Dart).
It also seems that GraphQL is slow, so it's a no-go. It's still food-for-thought.
Just posting this for future reference :)
After pushing https://github.com/dwyl/phoenix-todo-list-tutorial/pull/60 and https://github.com/dwyl/flutter-todo-list-tutorial/pull/28, it seems that the next step is tackling https://github.com/dwyl/technology-stack/issues/106.
Apparently, it's already in progress by you, @nelsonic . I can't seem to find any repo for this SPIKE. Should I create one? I've reference a bit of research on https://github.com/dwyl/technology-stack/issues/106#issuecomment-1353527524.
@LuchoTurtle apologies for the lack of clarity on https://github.com/dwyl/technology-stack/issues/106 I assigned to myself but it's not in-progress
:
Feel free to pick it up and build a quick prototype based on one of the Todo List Tutorials and demo it tomorrow. π
@LuchoTurtle it's good to get ahead.
I'm a huge fan of proactivity especially in learning tech/tools.
For integrating Phoenix
with Flutter
our goals it the fastest possible response times.
That means using Channels/WebSockets directly.
GraphQL
will add both latency and complexity to our App
so I'd prefer to avoid it unless there's a very good reason for having it. Ref: https://github.com/dwyl/learn-graphQL/issues/23
@LuchoTurtle when you're back at your desk, please recap the progress you've made on the API
so that we know where we are with this. π
As it stands, the API has all of the CRUD functionalities tested (unit
and definition
tests with Hoppscotch). For more context, see https://github.com/dwyl/mvp/issues/256. All of the required tasks were completed, except adding Authentication
, which was put on hold as auth
was undergoing a rebuild, as per your accounts.
According to https://github.com/dwyl/app/issues/273, one thing that is also yet to be tackled is how the documentation will be presented. Examples like Stripe
have been touted as great examples of API documentation. Since " we need to create world-class documentation. π", we ought to figure out how we want the API documentation to be presented.
The basic features of the MVP are missing in app
. As it stands, https://github.com/dwyl/flutter-bloc-tutorial is the most complete and closest to the MVP Flutter
example we currently have. It would be a matter of shifting the code to this repo and starting working on it so we tackle the Flutter
related tasks present on this issue.
Cool. Let's start the process of borrowing the flutter-bloc-tutorial
code as the starting point for the App
. π
Please add 10x more comments to the code so that the person reading it is reading a "story" not an equation.
Context
Part of the
dwyl
mission andmanifesto
is to be community driven. π« We want as many people as possible to feel empowered to contribute to the project(s) they use. π‘ π¬ π©βπ» π To streamline the "onboarding" of newpeople
we need to create world-class documentation. π That often involves writing beginner-focussed generic tutorials from first principals. π° The reason we write our examples/tutorials to be generic is so that more people can learn from them π and hopefully contribute to improving them. π€ So far, the plan is working ...! πbefore
we build theFlutter
App ... πTo prepare for building the
Flutter
version of theMVP
we need to:code
] tolearn-dart
: https://github.com/dwyl/learn-dart/issues/15Flutter
Counter Example: https://github.com/dwyl/flutter-counter-example/issues/5 π’Flutter
Todo List:Phoenix
Todo List Tutorial to have a basicAPI
https://github.com/dwyl/flutter-todo-list-tutorial/issues/18 that can be used as the "Backend" for theFlutter
Todo List. GOTO: https://github.com/dwyl/phoenix-todo-list-tutorial/issues/53items
to the mobile device usingdrift
See: https://github.com/dwyl/learn-flutter/issues/70Flutter
Stopwatch Tutorial: https://github.com/dwyl/flutter-stopwatch-tutorial/issues/1 β±οΈRoadmap πΊοΈ
[ ] Build an
API
with the features we want in the "Final" version of theApp
: https://github.com/dwyl/app/issues/273before
we can build the API we need:items
andtimers
e.g. via:PaperTrail
: https://github.com/dwyl/technology-stack/issues/106ids
foritems
andtimers
to enable Offline support with zero conflict. We have this inElixir
-land via: dwyl/cid we need to replicate this to: https://github.com/dwyl/dart-cid/issues/1[ ] Replicate the basic MVP features described in mvp/BUILDIT.md in
Flutter
[ ]
Flutter
MVP App Working in a Web BrowserMore to come ... But this list is already quite a lot of work! Pick off the issue/task you want to work on and get going! π