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 2 years ago.
Improve this question
I have experience with Sequelize and TypeORM. LoopBack looks like a good alternative, so I tested it. But it looks like LoopBack 4 is not a finished product; it barely has the needed features for a production application.
My question is: why the LoopBack team decided to publish an unfinished product?
there are a lot of companies and products on live using Loopback4.
Which features you missed from the new version?
I mean, the product is free, open source and built off of previously released, finished products. Releasing it allows them to both test functionality and be provided with feedback and aid in building the actual application. Lots of products are released before they are finished for these important reasons. If you read the documentation, it is a community built product.
Most frameworks are constantly being updated to add functionality, so 'finished' is not really a word that can be thrown around for a framework
While it is not finished, to say it barely has the needs to support a production application is very dependent on the type of application being built.
Related
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 3 years ago.
Improve this question
I'm a web developer and mobile applications. I have several clients which I manage in a hosting service with whm panel. Now I want to start using Google Cloud. My question is whether it is better to create a project for each client or to create a single project with a lot of space and there to store all the pages and databases. Please help me with this because I do not know what is the best practice
From my experience,
If your customer pays a fixed price for hosting it does not matter.
If you charge "pay as you go" then a separate project is the only way you can know how much exactly to charge.
Like Ken says, it is very difficult to predict your needs with so little information. One point to keep in mind: if you ever plan to turn over ownership of the project to the client, then having a separate project for each client will make life so much easier.
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 7 years ago.
Improve this question
Aspnet vnext is still in beta version, and we are about to start a new application, and we considering to using aspnet vnext, i would like to know if it is a good a idea, someone is already running application in production with vnext?
Depends on whether you can wear the risk of implementing a project on an unfinished framework. Items that affect this risk include;
Expected size of your application
Other libraries you intend to use
Platform you intend to target
Whether you can afford the learning curve (there are changes)
Whether you are happy to spend time upgrading when its finally released
Whether you want to deal with implementing workarounds when you find features that are not working as expected.
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 7 years ago.
Improve this question
While using Gitflow, what is the reason for separating branch naming to feature vs bugfix vs hotfix?
I.e. why not just, for example, instead of:
feature/
bugfix/
hotfix/
Just do:
change/
What does separating by feature/bugfix/hotfix buy?
Great questions and the answer really depends on how you sort your git. The branching model and gitflow in general is trying to give us some order in the chaos that commits are just after a couple of days.
The image below shows you what they though makes most sense.
(As far as I know it all came from this blog post by Vincent Driessen)
Separating your hotfixes which merge directly into master and your bugfixes which merge into dev makes it easier to go with your product cycle.
The idea is you build your app, create features, make a release candidate (beta test) and then release your app. Hotfixs can be necessary at any time after this. No point in going back all the way to the feature branch and issuing a bug fix there as the feature may already been developed further.
Does that make sense?
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 8 years ago.
Improve this question
I am preparing to do some open-source development that I have been thinking about for some time. It will ultimately be a cloud-based web service that interrogates other web services. As one of the joys of this work, I can call the shots and return to my 90s-era Smalltalk roots. I've settled on Pharo and (at least initially) Seaside. But it has been almost 15 years since my last real Smalltalk work. So I am unfamiliar with the current ecosystem. Which versions of Pharo and Seaside are stable enough for real work? And where and what else do you suggest a returning Smalltalker explore before beginning? Thanks!
Well, the stable version is Pharo 2.0 and Seaside 3.0.9.
(Both pharo 3 and seaside 3.1 are already a lot better, but since they are development versions, I wouldn't recommend them for production yet).
You will probably need Zinc to interrogate web services: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Zinc/Zinc.pier.html
I can only encourage you to join the Pharo users mailing list and IRC channel.
You may also want to have a look at the books: http://www.pharo-project.org/documentation/tutorials-books
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 4 years ago.
Improve this question
Are there any best practices to keep in mind while designing API's which ensures backward compatibility and new version releases. Any links to articles/blogs is appreciated.
You should check out this presentation about API design. It's from Google and pretty good.
It also addresses backward compatibility and new releases.
How to Design a Good API and Why it Matters
keep both running, with version in the url. api.mysite.com/[version]/api/url/here. Notify the users when a new version of the API arrives, and drop the old version after a while. Either when it isn't used anymore, or like 6 months insuring the users had enough time to change it.
Or keep it running forever, but don't deliver any new functionality for it.
The best way to do this to keep the old interface or class in new release with new interface and classes and marked them as deprecated (means those will be removed in future release).
Hear API designer keep in mind about difference between public interface and published interface.