Alternative à Parse
Terflogag
Membre
Bonsoir,
Comme certains le savent peut être déjà , Parse ferme ses portes prochainement... Mon choix s'était porté vers ce service avec dans l'idée qu'il perdurerai dans le temps grâce à son rachat par Facebook : c'est raté !
Quel sont les autres (solide) alternatives ?
Bonne soirée
Comme certains le savent peut être déjà , Parse ferme ses portes prochainement... Mon choix s'était porté vers ce service avec dans l'idée qu'il perdurerai dans le temps grâce à son rachat par Facebook : c'est raté !
Quel sont les autres (solide) alternatives ?
Bonne soirée
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Oui, pour une application destinée à une seule plateforme.
Autre inconvénient, est-ce qu'on peut attaquer CloudKit en JS ou autre serveur ? Je ne crois pas.
Il y a FireBase de assez connu:
https://www.firebase.com
Pour ceux qui veulent mettre les mains dans le cambouis, je suis tombé sur cela un jour:
http://kinto.readthedocs.org/en/latest/overview.html
Voilà une liste à débroussailler:
http://aws.amazon.com/mobile/?nc1=h_ls
https://www.firebase.com
https://syncano.io
https://stamplay.com
https://backendless.com
https://www.moback.com
https://www.rapidapi.com
https://www.backand.com
https://www.built.io
Pour ma part, j'ai fait le choix de gérer moi-même le backend (pas de mauvaise surprise, mais ça demande du temps et de l'apprentissage...).
https://azure.microsoft.com/fr-fr
firebase
Après j'ai pas essayé personnellement mais bon ça peut quand même valoir le coup de lui laisser une chance.
Je n'écris pas ça pour troller " du moins, pas uniquement " mais faire confiance à Apple pour n'importe quel service web que ce soit, c'est prendre trop de risques. Le jour où ils sauront donner des informations correctes sur leur page http://www.apple.com/support/systemstatus/, je pourrai envisager d'éventuellement essayer à petite échelle.
C'est quand même assez incroyable la fermeture de Parse... L'interface venait de faire peau neuve et était encore en Bêta, en plus de quelques nouveau services. Racheter une boà®te pour la faire fermer quelques années plus tard sans détails, merci Facebook.
https://github.com/relatedcode/ParseAlternatives
Faire soi-même le back-end n'est peut-être pas une mauvaise idée pour des petites apps.
Je trouve que le côté serveur a été maintenu trop longtemps dans l'obscurantisme, c'est historique.
C'est pas si compliqué que cela en fait.
Le problème c'est que:
soit on est 'à poils' avec son linux,
soit on doit utiliser une grosse artillerie type php, rails, etc. qui impose plein de contraintes.
Ce qui manque c'est d'avoir un service de mise à jour qui appliquerait tous les patchs de sécurité linux et serveurs (nginx) de manière semi-automatique et qui serait en SSL par défaut sans qu'on ait à se prendre la tête.
Par exemple dans le cadre d'une startup ou du test d'une idée je pense qu'il est préférable de passer plus de temps sur le front que sur le backend.
La suite viens naturellement si le succès est au rendez vous après. Bien que, bien entendu le fait de changer tout ça engendre d'important coût supplémentaire...
Pour un pro avec un peu d'expérience, cela ne devrait pas être plus long que de se mettre à un nouveau langage ou à un nouvel environnement de développement.
Louer un serveur virtuel, installer nginx, installer un serveur FastCGI, SimpleCGI ou http derrière pour traiter les requêtes.
Basta.
Et, au moins, on apprend quelque chose. Un problème avec les solutions clés en main type Azure, CloudKit ou Parse c'est qu'on apprend rien d'autre qu'à les utiliser.
Si ça commence à marcher, on essaye de bien sécuriser et de bien répartir la charge...
Ou alors tout coder en Swift avec Perfect.org? :°)
Potentiellement la raison pour me mettre au Swift.
Ok, je ne savais pas.
Reste que tes données sont toujours sur les serveurs d'Apple (juste un constat, pas une critique). J'aime bien être maà®tre de "mes" données.
Je suis en train de le faire.
Mais c'est bien plus long. Il y a beaucoup de choses à apprendre.
Ubuntu
ssh sécurisé
iptables, ufw
nginx, passenger
ruby
rails
mariadb
ssl
elasticsearch
...etc
ça prend du temps.
Le plus problématique, c'est la sécurité.
Effectivement apprendre tout ça est clairement une perte de temps la majorité du temps, après cela n'est que mon avis !
Après avoir regardé FireBase de plus prêt ainsi que deux ou trois autres service, aucun ne me semble aussi agréable et aussi complet que Parse...
Avez vous des API sympa pour l'intégration des notifications ?
Je n'aimais déjà pas (pour ne pas dire détester) Facebook avant, mais alors maintenant je vous laisse imaginer...
C'est une perte de temps mais pas forcément d'argent... cela dépend de la quantité de données à faire traiter par un Parse & Co.
Après avoir fait le tour de pas mal de service, la plupart commence à proposer des services de migration pour appâter le client !
Je pense que d'ici quelques semaine la migration sera bien plus simple, il est préférable d'attendre plutôt que de se lancer dans une refonte des applications...
Pour faire simplement du Push ;
Je me suis toujours demandé pourquoi un produit très simple comme EasyAPNS n'est pas suivi ?
Certes il n'est bien sûr pas aussi poussé que Parse mais pour une petite appli il suffit largement... non ?
C'est beaucoup plus difficile que tu ne le dis.
J'avais essayé de développer un petit site en Rails il y a quelques années, et autant développer en Rails était très faisable, autant le déploiement paraissait une somme énorme de difficultés. Je devais justement installer un tas de trucs qui renvoient des messages incompréhensibles et qui ne fonctionnent jamais comme dans le tutoriel.
Je ne suis pas administrateur système, et tout cela est très éloigné de mon travail quotidien. Alors oui, utiliser un service comme Parse est plus évident pour moi.
https://github.com/relatedcode/ParseAlternatives
C'est quand c'est difficile qu'on progresse. C'est une maxime valable dans les activités physiques mais aussi intellectuelles.
Cela dit, je me suis mal exprimé. Mais j'ai bien employé le conditionnel !
Je voulais dire qu'on devrait pouvoir démarrer un backend sans Framework, ni service.
C'est-à -dire en utilisant juste du code et quelques librairies, comme on peut le faire sur n'importe quelle autre plateforme.
Le seul service dont on a vraiment besoin c'est la location d'un serveur (avec maj de sécurité incluse, si cela existe).
Quand je démarre le développement sur une nouvelle plateforme, je démarre avec "hello world" et j'évolue à partir là . Je ne vais pas tout de suite installer un Framework d'app complet qui gère tout à ma place.
Une fois que j'ai compris comment cela fonctionne, alors j'intègre des librairies et des Framework petit à petit au fur et à mesure des besoins.
Mais, côté backend, non ! Il faut tout de suite choisir un grosse usine à gaz qui va tout faire en cachant la manière dont cela fonctionne vraiment.
Et le pire c'est qu'il en sort une nouvelle tous les ans, alors que l'infrastructure et les protocoles d'internet ne changent pas tant que ça.
A mon avis c'est purement lié à l'historique du domaine qui, par nature, a toujours été moins facile d'accès que les plateformes desktop ou mobile.
Mais, je pense qu'on peut très bien avoir cette approche incrémentale pour le backend même si c'est vrai que cela demande un peu plus de recherche.
Il me semble que le problème est que nous avons justement besoin d'un backend qui tienne la route d'un point de vue fonctionnel et sécuritaire, et personnellement, je n'ai ni les compétences, ni le temps d'apprendre. Alors, mon choix est de filer le boulot à quelqu'un qui sait, ce qui me coûte cher et me rend dépendant de cette personne, ou de faire appel à un service qui est fiable et bon marché... le choix est vite fait.
Il y a Heroku (ou Scalingo[FR]) qui propose d'héberger son propre serveur Parse.
Perfect est une brique de base pour faire son propre backend.
Bien sûr, cela revient à réinventer la roue. D'un autre côté, on gagne en contrôle.
Si d'emblée, on a besoin de tous les services fournis par Parse ou équivalent, autant prendre Parse, c'est sûr.
Mais si on s'engage dans un projet à long terme, ça peut valoir le cout de faire son propre backend. Au pire, on aura appris des choses pour le temps dépensé.
Par exemple, développer un équivalent de EasyAPNS en Swift en utilisant Perfect ou un autre framework Swift n'est pas hors de portée.
Bien-sûr si on est débutant en développement iOS, cela représente trop de choses à apprendre d'un seul coup.
Swift peut être une opportunité pour les développeurs iOS de se réapproprier le backend ; même s'il faudra attendre encore quelque mois pour avoir un framework prêt pour la prod (Swift sous Linux n'est pas encore stabilisé, GCD n'est pas terminé et le portage de Foundation vient de démarrer).
Pour une faisabilité, j'ai monté un petit framework basé sur Simple CGI avec un principe de closures un peu inspiré de OHHTTPStub.
Les sources sont dispo sur github.
On peut tester avec une installation de Ubuntu sous VirtualBox, ou sous OSX.
Voici un exemple d'application REST minimaliste utilisant le framework et qui tourne sur un serveur virtuel chez Linode.
Firebase viens de sortir une importante mise à jour, qui pour moi change tous ces classements
Notifications, Database, stockage, analytic etc....
https://firebase.google.com