I am using flutter as my main framework for building cross-platform apps.
Until this very day, I used Firebase and it was wonderful but I want to expand my knowledge and learn to build full-stack mobile apps.
I was roaming around the web for several days now, and I can't seem to set my mind on backend language to go with flutter.
I am looking for a language that is up to date and much needed in the industry, so don't worry if it is overkill for small apps (I just want to practice for now). and in addition, I need it to go well with the bloc pattern recommended by Google.
I have heard that scala and play are great backend services. also, that ruby on rails is going well with the bloc pattern.
I would like to hear your thoughts and opinions about the situation, what would you choose and why? (In general, not between scala play and RoR)
Thanks a lot in advance!
IMHO, you should to define target tasks, that you will solve.
For example, our company engaged in computer vision and deep learning problems. We choose flask or fastapi python frameworks to build our backend rest-api prototypes, because it`s easy to integrate with tensorflow or pytorch solutions. If we have bottleneck somewhere, that microservices are rewriting in .Net.
If you looking for the most demanded language or framework, see upwork jobs or similar sites to understand, what does the market need today.
Related
I'm a backend developer with background of Java and Python. I've started with Flutter 3 months ago. I find Dart an easy language to learn and fun to write code in. Google did a good job there.
What is challenging for me is figuring out best practices when working with flutter. The official documentation (docs.flutter.dev) is good and it's also interesting to look at the Dart code powering the framework. But I haven't seen a resource that goes over best practices for design/architecture of a Flutter application.
In particular, I'm interested in how to maintain separation of concerns between Database , Domain and Presentation layers.
I'm using Firebase Store for my (realtime) database. The API provides the data in the form of a JSON object (Map). This is fine, but I want to translate this into my own domain model instances (for data validation, enrichment and enforcing other business rules). What I don't know is how to bridge the gap between database and UI (Widgets). I want to keep a Clean Architecture, and would like to learn how to do this correctly. I should also add that I don't have prior experience with Asynchronous code, which seems to be an important skill to gain.
I've experimented in using InheritedWidgets to try and expose my data to the UI/Presentation layer as model instances, without the UI knowing about the specifics of the database, but ran into difficulties because I don't understand the Flutter framework and Dart async programming very well. I also know there are frameworks like Bloc that are supposed to solve data/state management issues. But as much as possible I want to stick to the basics before I start using more elaborate and heavier tools.
What recommended resources are out there that I'm missing, that could help me become a better Dart/Flutter developer?
With the recent announcement of Hummingbird, it looks like Flutter will mature for web apps. I was trying to learn AngularDart, but I personally believe Flutter web apps will be a better approach. I'd have to plan a lot to share my codebase between Flutter and AngularDart.
Will Hummingbird receive support for Flutter web apps? Does the use of AngularDart will have diminishing returns in the future?
I understand the answers might be very subjective, but maybe it would be better to discuss some serious advantages and disadvantages of flutter-web.
Update (13.09.2019) Hummningbird is now Flutter-Web and Flutter-Web is now merged to Flutter branch. Things have changed for good ;)
As always, the answer is: It depends.
If you want to reach a lot of users quickly, AngularDart is your friend as it provides a solid foundation right now.
Also notice that doing a lot of "planning to share your codebase", which basically translates to thinking about separating your business logic from your UI logic, is a win either way because the more modular code will benefit you in the long run.
Additionally, it's never a bad thing to get to know more frameworks.
However, if you can allow yourself to be patient and you're thinking in the long term, Flutter's future support for web and Fuchsia may intrigue you.
That's why - if you believe in Flutter's success - it can make sense to only develop for Flutter and then wait and see what's about to happen.
Personally, I believe Flutter will become a well-supported, versatile, general UI framework.
That's why I would recommend betting on Flutter if your project is not time-critical.
I think it really depends on your use case. AngularDart and angular_components are trying to support a more 'enterprise' use case. Complex web apps that are primarily desktop focused. While HummingBird is focusing more on the mobile web use case or where you already have a flutter app that you happen to want to target web also with the same target. So both will have a place.
I understand you very wel ;-)
I'm now tryin to recycle my carrer and been a lot of months learning Angular (The Typescript branch) I love work with it, so pleasant an so intuitive, I did some major web apps than are working very well ant the mantainence is easy, quick and clean ... the future seemed me and Angula in a long love afaire ...
But sudenly I hear about Flutter, like two monts ago, and I was captivated for the concept (before I already had try different aproachs to have one codebase an reach all mobile platforms, Xamarin in major part, and was painfull to learn and to use, ReactNative never make me feel anything), but Flutter is soo easy, with so much power than Xcode and Swift witch I been workin too and with wich when you have a middle project the storyboard is intelligible. I been learning Flutter full time last two months, already have app in appstores and doing my first web (wonderfull experince doing web without css, ohhhh yes).
Then my opinion is similart to the others "depends", but if I was you and was just starting to learn AngularDart I will go for Flutter without loocking back.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There is an old php base website which provides a single service and is working for many years. Now we have decided to change the website itself to become more modern and faster and at the same time providing an app for it and we are going to hire some people for that. As I'm a developer myself (a c++/go fan and mostly in machine learning area) I want to know what are the best options to choose when such thing is needed. I personally think that the whole back-end should work as a RESTful API and then probably something like react and react-native in front for both web and mobile but I'm not sure if this is the best decision we can make.
I want to know what other people with same requirements have done ? Some people recommended us meteor but it seems to be changing very fast and we really need some stable and mature solution without too much maintenance.
Looking forward to hearing your suggestions
I'm a big fan of the REST API + front-end JS framework architecture.
One option would be to build an API with Ruby on Rails. The "rails generate new" command includes an --api option for generating a Rails application that lacks views and serves JSON. You can learn more about building APIs with Rails on the rails-api gem GitHub page. (Keep in mind the rails-api gem has since been rolled into Rails proper.)
Overall, Rails is a fast way to get a services layer up and running. It's fairly simple, and might be a good option for your app, which as you said, provides just one service. However, Rails is also powerful enough to support a much more substantial API.
If you want a REALLY simple Ruby-based services layer, you should check out Sinatra. You could also go full Javascript with Express. It's about as simple as Sinatra.
If you have a background with C++ and Go, you may not want to jump headfirst into these web-heavy technologies. Consider using Java Spring for your services layer. (I would link but I don't have enough rep. Haha)
As far as the front-end goes, you're on the right track with React and Meteor. I'm personally a fan of Angular (specifically Angular 2). It's a really popular JS web app framework -- great for asynchronous Javascript and single page applications. Granted, Angular has a steep learning curve to start, but if you're willing to climb, it pays off.
Let me know if you have any specific questions! Good luck.
Meteor is a bit heavy if all you want is a web site. It depends how much interactivity you want - if it's more of an app, then it's worthwhile doing, and if you want to do ios and android apps, then Meteor is pretty fast to get up and running.
I would recommend to choose a technology that either you are keen to learn, or you have some skills in already. Learning curves mean longer projects.
If you need native mobile application and interactive site than react and react-native with pure API server is a really good solution. I developed several similar services and very satisfied with this combination.
First of all you can share API access layer and part of business logic between both clients.
Second you are using identical technologies on mobile and web. However mobile application has real native UI because React Native don't use browser.
Thirdly server becomes more simple, maintainable and scalable.
Personally I prefer WebSockets as network protocol (look at amazing Go gorilla websocket implementation). But if you need support old browsers or prefer more classic REST API than it's ok also.
Answering based on my comment above, this is all opinionated, but I find that Node/JavaScript tends to be about the best bang for the buck, if all you are trying to do is get through proof of concept stage, and possibly scaling from there. Depending on your back-end needs, you may want to migrate parts, or whole to Go or Python.
On the Front end, using web tooling (mostly centered around node and npm), I would build the primary UI with React and the material-ui components... Targeting a web/browser interface... you can then extend this, in order to support more native-like features. You can build "native" versions using Cordova for Android and iOS. You can use electron as a base for desktop versions.
For the backend, node is a nice place to start, and I feel RethinkDB is a great database for many use cases (despite the changes from commercial to open platform happening now). Mongo is another option, and there are hosted/managed options through a few providers. Alternatively, I'd probably lean towards PostgreSQL via Amazon.
The API server, I'd definitely do a first pass with Node, and then, as needed rewrite whole, or in parts with Go or Python... Go will have better performance and scale without compromising some of the ease of development aspects. Python has very rich tooling, if you need more flexibility than performance for some areas. There are other options, C# is becoming a very good cross-platform option, which I happen to really appreciate as a language. The performance there is very good, though you may find some constraints less appealing than JS or Python.
YMMV with any of these choices.
i read a lot about frameworks like LARAVEL. I am currently trying to build my own RESTful web service. But doing that "by hand". I have absolutely no experience with these framework systems. It might be a general question, but I want to get your point of view on that.
What is a best practice to that. Is it "useless" building a web service from the ground up and it is common to use this framework? And what is the advantage. I do not want to start all over again and again by finding out that I should have started directly with these kind of frameworks to build the web service.
What are your opinions on that? Manually build everything? Or never do that!
Laravel will save you a lot of time in the long run. A lot of tools are pre-built, and a lot of problems that you will run into are already solved. In my opinion it's well worth it to start with the framework. You will gain skills that will help you out on future projects.
I am about to start building an app that will be used across all platforms. I will using monotouch and monodriod so I can keep things in .net
I'm a little lazy so I want to be able to reuse as much code as possible.
Lets say I want to create an application that stores contact information. e.g. Name & Phone number
My application needs to be able to retrieve data from a web service and also store data locally.
The MVVM pattern looks like the way to go but im not sure my approach below is 100% correct
Is this correct?
A project that contains my models
A project that contains my views,local storage methods and also view models which I bind my views to. In this case there would be 3 different projects based on the 3 os's
A data access layer project that is used for binding to services and local data storage
Any suggestions would be great.
Thanks for your time
Not specifically answering your question, but here are some lazy pointers...
you can definitely reuse a lot of code across all 3 platforms (plus MonoWebOS?!)
reusing the code is pretty easy, but you'll need to maintain separate project files for every library on each platform (this can be a chore)
MVVM certainly works for WP7. It's not quite as well catered for in MonoTouch and MonoDroid
some of the main areas you'll need to code separately for each device are:
UI abstractions - each platform has their own idea of "tabs", "lists", "toasts", etc
network operations - the System.Net capabilities are slightly different on each
file IO
multitasking capabilities
device interaction (e.g. location, making calls etc)
interface abstraction and IoC (Ninject?) could help with all of these
The same unit tests should be able to run all 3 platforms?
Update - I can't believe I just stumbled across my own answer... :) In addition to this answer, you might want to look at MonoCross and MvvmCross - and no doubt plenty of other hybrid platforms on the way:
https://github.com/slodge/MvvmCross
http://monocross.net (MVC Rather then Mvvm)
Jonas Follesoe's cross platform development talk: Has to be the most comprehensive resource out there at the moment. He talks about how best to share code and resources, abstract out much of the UI and UX differences, shows viable reusable usage of MVVM across platforms and nice techniques for putting together an almost automated build. (yes, that includes a way for you to compile you monotouch stuff on Visual Studio)
Best of all he has a available source code for the finished product and for a number of the major component individually placed in its own workshop project and a 50 + page pdf detailing the steps to do so.FlightsNorway on github
IMO the only thing missing is how best to handle local data storage across all platforms. In which case I would direct you to Vici Cool Storage an ORM that can work with WP7, MonoTouch and (while not officially supported) MonoDroid.
*Disclaimer* The site documentation isn't the most updated but the source code is available. (Because documentation is Kriptonite to many a programmer)
I think the easiest way to write the code once and have it work on all three platforms will probably be a web-based application. Check out Untappd for example.
You can start by looking at Robert Kozak's MonoTouch MVVM framework. It's just a start though.
MonoTouch MVVM