dwyl/product-roadmap

EPIC: `Flutter` MVP 📱

nelsonic opened this issue · 10 comments

nelsonic commented

Context

Part of the dwyl mission and manifesto 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 new people 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 the Flutter App ... 📝

To prepare for building the Flutter version of the MVP we need to:

Roadmap 🗺️

  • Build an API with the features we want in the "Final" version of the App: dwyl/app#273

    • before we can build the API we need:
      • Version control (history) for our items and timers
        e.g. via: PaperTrail: dwyl/technology-stack#106
      • Use globally unique ids for items and timers to enable Offline support with zero conflict.
        We have this in Elixir-land via: dwyl/cid we need to replicate this to: dwyl/dart_cid#1

  • Replicate the basic MVP features described in mvp/BUILDIT.md in Flutter

  • Flutter MVP App Working in a Web Browser

    Note: Why Web? Our reasoning for focussing on Web for our MVP is always the same:

    • Zero barriers to deployment: there are no gatekeepers (App App Store or Google Play Store reviewers)
    • Zero hurdles to adoption/trial: people wanting to try the App can get started immediately; nothing to install.
    • Zero device constraints e.g. people in a School/Corp env that cannot install native Apps can still use a Web App.

    As noted in dwyl/technology-stack#81 (comment) Flutter for Web still has not solved the SEO problem. So we still want to have a "traditional" web app to render the content that will be public to maximise SEO`.

More 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! 🙏

LuchoTurtle commented

I'm working on this as I go along. I've already created the PR for dwyl/learn-flutter#68 so that should tick that off.

I'm finishing the dwyl/flutter-counter-example#5 issue as well. Currently re-writing the README so it's up-to-date and correctly formatted.

  • 👍1
LuchoTurtle commented

An update on this:

Wanting to get all of these sorted before passing on to the Roadmap section.

  • 👍1
nelsonic commented

@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: dwyl/phoenix-todo-list-tutorial#53 🙏
Please LMK if this is clear and if you need any help with any of this. 👌

LuchoTurtle commented

Perhaps I'm getting ahead but I was looking at options for integrating Flutter with Phoenix and a few questions arose.

Channels

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.

API

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 :)

LuchoTurtle commented

After pushing dwyl/phoenix-todo-list-tutorial#60 and dwyl/flutter-todo-list-tutorial#28, it seems that the next step is tackling dwyl/technology-stack#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 dwyl/technology-stack#106 (comment).

  • 👍1
nelsonic commented

@LuchoTurtle apologies for the lack of clarity on dwyl/technology-stack#106 I assigned to myself but it's not in-progress:
image

Feel free to pick it up and build a quick prototype based on one of the Todo List Tutorials and demo it tomorrow. 👍

nelsonic commented

@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: dwyl/learn-graphQL#23

  • 👍1
nelsonic commented

@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. 🙏

LuchoTurtle commented

As it stands, the API has all of the CRUD functionalities tested (unit and definition tests with Hoppscotch). For more context, see dwyl/mvp#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 dwyl/app#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.

  • 👍1
nelsonic commented

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.