Rest API taal

[peize9]

Dag Tweakers,

Ik sta momenteel een beetje voor een keuze en ik weet niet echt wat ik het beste kan doen. Ik ga een rest api maken om zowel websites als computer software te verbinden met een database(mysql). Ik kan alleen echt geen keuze maken en ik wou vragen wat de ervaringen van jullie is.

Momenteel zat ik te denken aan Jboss/Wildfly, PHP of spring. Ik heb ervaring met php en met java ook een beetje maar verder nog niet met spring. Ik weet alleen niet of php een goede keuze is omdat je toch vaak negatieve dingen er over hoort en ik graag wil dat het future proof blijft.

Hebben jullie tips over wat ik het beste kan doen?

Alvast bedankt,
Dany

[page404]

Dat hangt denk ik heel erg af wat je verwacht van schaalbaarheid, benodigde libraries en welke database je gebruikt. Kortom, niet heel simpel te beantwoorden.
Je noemt Java EE of Spring, volgens mij is Java de taal en Spring het framework voor Java, dus het lijkt of je dingen door elkaar haalt. Maar ik kan me ook vergissen aangezien ik weinig Java kennis heb.

Als je een moderne API backend gaat bouwen moet je denk ik op zijn minst Node.js, Swift en Python overwegen, en welllicht ook C# als dat je ding is. Ofwel, keuze genoeg. Doe eens een paar Proof of Concepts met verschillende talen en kijk wat werkt voor je.

[peize9]

page404 schreef op zaterdag 1 mei 2021 @ 19:34:
Dat hangt denk ik heel erg af wat je verwacht van schaalbaarheid, benodigde libraries en welke database je gebruikt. Kortom, niet heel simpel te beantwoorden.
Je noemt Java EE of Spring, volgens mij is Java de taal en Spring het framework voor Java, dus het lijkt of je dingen door elkaar haalt. Maar ik kan me ook vergissen aangezien ik weinig Java kennis heb.

Als je een moderne API backend gaat bouwen moet je denk ik op zijn minst Node.js, Swift en Python overwegen, en welllicht ook C# als dat je ding is. Ofwel, keuze genoeg. Doe eens een paar Proof of Concepts met verschillende talen en kijk wat werkt voor je.

Sorry, met Java EE bedoelde ik Wildfly.

[Kalentum]

Het eenvoudigste antwoord is: "De taal waar je zelf de meeste ervaring mee hebt".

De reden is voornamelijk efficiëntie: je levert sneller een werkend product omdat je minder hoeft te leren.

Ik zou persoonlijk python of ruby kiezen. Omdat ik daar meer van weet. Als ik in jouw schoenen zou staan dus PHP of Java.

Alle gangbare talen voldoen verder, op basis van de informatie die je geeft. Dus het maakt niet zoveel uit.

Maar ja, is het hobby? Spelen kosten een rol? Is er een datum waarop een versie 1 moet werken? Is het voor jezelf of ook voor anderen?

[peize9]

Kalentum schreef op zaterdag 1 mei 2021 @ 20:08:
Het eenvoudigste antwoord is: "De taal waar je zelf de meeste ervaring mee hebt".

De reden is voornamelijk efficiëntie: je levert sneller een werkend product omdat je minder hoeft te leren.

Ik zou persoonlijk python of ruby kiezen. Omdat ik daar meer van weet. Als ik in jouw schoenen zou staan dus PHP of Java.

Alle gangbare talen voldoen verder, op basis van de informatie die je geeft. Dus het maakt niet zoveel uit.

Maar ja, is het hobby? Spelen kosten een rol? Is er een datum waarop een versie 1 moet werken? Is het voor jezelf of ook voor anderen?

Het is hobbymatig nog ja, maar wie weet kan het doorgroeien. Er zit verder geen deadline aan en kosten... tja het speelt niet echt een rol. PHP zou voor mij het makkelijkste zijn, maar de meeste devs die ik spreek zijn daar erg negatief over. Ik denk dat ik dan het beste Java kan doen... Dan is het nog kiezen tussen Wildfly of Spring...

[Tsurany]

Ik zou zeggen begin met wat je kent, dat werkt het snelst. Je kan altijd de API's vervangen door iets geschreven in een andere taal, desnoods een voor een upgraden.

Zorg er vooral voor dat je de REST standaarden juist gebruikt en een micro service architectuur aanhoud. Dan is een API vervangen echt plug en play.

[Un93m59]

Tsurany schreef op zaterdag 1 mei 2021 @ 22:51:
Ik zou zeggen begin met wat je kent, dat werkt het snelst. Je kan altijd de API's vervangen door iets geschreven in een andere taal, desnoods een voor een upgraden.

Zorg er vooral voor dat je de REST standaarden juist gebruikt en een micro service architectuur aanhoud. Dan is een API vervangen echt plug en play.

Microservices ja? zonder exact de use case van TS te weten lijkt dit me te complex

[Tsurany]

Un93m59 schreef op zaterdag 1 mei 2021 @ 23:05:
[...]

Microservices ja? zonder exact de use case van TS te weten lijkt dit me te complex

Wellicht, al lijkt het me wel bij deze use case passen. Hoe micro je de services maakt is dan te bezien.

[NMe]

peize9 schreef op zaterdag 1 mei 2021 @ 22:45:
[...]

Het is hobbymatig nog ja, maar wie weet kan het doorgroeien. Er zit verder geen deadline aan en kosten... tja het speelt niet echt een rol. PHP zou voor mij het makkelijkste zijn, maar de meeste devs die ik spreek zijn daar erg negatief over. Ik denk dat ik dan het beste Java kan doen... Dan is het nog kiezen tussen Wildfly of Spring...

Developers die per definitie negatief zijn over PHP hebben het doorgaans zelf al jaren niet meer aangeraakt. PHP is al jaren niet meer het blunderkindje van Rasmus Lerdorf maar sommige mensen doen graag alsof dat wel nog steeds zo is. En specifiek voor jouw vraag is API Platform echt enorm fijn om te gebruiken.

[downtime]

peize9 schreef op zaterdag 1 mei 2021 @ 19:21:

Hebben jullie tips over wat ik het beste kan doen?

Ja. Ik maak uit de vraag op dat je nog weinig ervaring hebt en feitelijk nog moet leren programmeren. Een REST API kun je in elke moderne taal maken. Begin gewoon met een taal die jou aanspreekt en begin gewoon. De beperkende factor ben jij zelf.

Maak je niet te druk over wat anderen van een bepaalde taal vinden. Het halve internet, waaronder hele grote sites, werkt op PHP en dat gaat goed. Ja, er wordt hele slechte software in PHP geschreven, maar dat komt omdat het wordt geschreven door mensen uit de “maar het werkt toch” school die voor zichzelf de lat laag leggen en niet omdat je in PHP niets goeds kunt maken. Als jij de ambitie hebt om goede software te schrijven, en niet alleen maar “iets wat werkt”, dan kun je dat ook in PHP.

[Lethalis]

Ik las ooit ergens in een soortgelijke discussie het volgende:

While we are arguing over which language and framework is better, somewhere someone is building the next Facebook with PHP.

Kortom, doe wat voor jou het makkelijkste is. Zorg ervoor dat je een werkend prototype hebt, kijk dan eens wat je ermee kan en of het zinvol is.

Dat je dan misschien ooit versie 2 in een andere taal maakt, is ook geen ramp zolang de interface hetzelfde blijft.

[fietser1997]

Mocht je de keuze maken voor Java is mijn advies om te kiezen voor Spring. Dit kun je eventueel met hibernate doen. De guides van spring zijn duidelijk en simpel.
Daarnaast heb support spring t/m java 14 op dit moment de upgrades tussen java 8 en 14 voor spring applicaties. Zijn ook goed gedocumenteerd dus ik verwacht dat 1 tot 4 uur werk alles is wat je nodig hebt om naar de eerst volgende LTS te gaan. Java 17.

[peize9]

Zit er trouwens nog veel performance verschil tussen Java EE en PHP?

[kwaakvaak_v2]

peize9 schreef op zondag 2 mei 2021 @ 16:48:
Zit er trouwens nog veel performance verschil tussen Java EE en PHP?

Heb je die performance nu al nodig dan? Vooraf je druk maken over performance is 100% verspilling van je energie

[peize9]

kwaakvaak_v2 schreef op zondag 2 mei 2021 @ 16:56:
[...]


Heb je die performance nu al nodig dan? Vooraf je druk maken over performance is 100% verspilling van je energie

Nope, maar ik vind de keuze nog steeds moeilijk dus zit ik maar een beetje te zoeken naar andere redenen om specifiek iets te kiezen.

[NMe]

peize9 schreef op zondag 2 mei 2021 @ 16:48:
Zit er trouwens nog veel performance verschil tussen Java EE en PHP?

Da's hetzelfde als vragen of mannen sneller kunnen rennen dan vrouwen. Zelfs met in het achterhoofd dat mannen vaak sneller zijn rent een vrouwelijke atlete met gemak rondjes om de gemiddelde man heen. Datzelfde geldt voor jou, het hangt van je precieze usecase of welke van de twee sneller is, en zelfs dan is het nog maar de vraag of het überhaupt interessant is voor wat je aan het bouwen bent dat iets marginaal sneller zou kunnen in een andere taal.

[ Voor 4% gewijzigd door NMe op 02-05-2021 18:51 ]

[Lethalis]

peize9 schreef op zondag 2 mei 2021 @ 16:48:
Zit er trouwens nog veel performance verschil tussen Java EE en PHP?

Het gaat zeer waarschijnlijk niet de bottleneck zijn. De datastore is wat dat betreft waarschijnlijk belangrijker.

Als ik op mijn werk performance issues moet onderzoeken kom ik in 95% van de gevallen bij SQL Server uit. En dan ligt het vaak aan een ontbrekende index, of een ernstig gefragmenteerde.

De overige 5% heeft iemand enorm geblunderd, maar dat kan dus in elke taal (in ons geval C#).

[ Voor 33% gewijzigd door Lethalis op 03-05-2021 08:35 ]

[Lethalis]

peize9 schreef op zondag 2 mei 2021 @ 16:59:
[...]

Nope, maar ik vind de keuze nog steeds moeilijk dus zit ik maar een beetje te zoeken naar andere redenen om specifiek iets te kiezen.

Bij een hobby project moet je jezelf gewoon serieus afvragen wat het doel is.

Wil je snel iets hebben draaien? Kies wat je het beste kan. In jouw geval PHP? Wil je juist iets nieuws leren wat ook zinvol is om later geld mee te verdienen? Dan is Java (Spring) of .Net 5 (ASP.Net) bijvoorbeeld een goede keuze.

Met Spring Boot kun je vrij snel iets hebben. Met .Net 5 ook. Voor beide is er veel documentatie, en zijn er veel tutorials te vinden.

PHP ben ik zelf dan niet zo in thuis. Ooit 20 jaar geleden gedaan. Maar daar zijn tegenwoordig ook hele frameworks voor en de taal is ook een stuk verder als ik mensen hier mag geloven.

[Hydra]

peize9 schreef op zaterdag 1 mei 2021 @ 19:21:
Momenteel zat ik te denken aan Jboss/Wildfly, PHP of spring.

@Lethalis heeft het belangrijkste al gezegd maar als Java developer kan ik je aanraden dat als je voor Java gaat, ga dan voor Spring Boot. Het is makkelijker en heeft veel meer beschikbare informatie dan 'ouderwetse' app server deployments met Java EE.

Mocht je toch perse voor Java EE (tegenwoordig Jakarta EE) willen gaan, kijk dan naar Microprofile.

[Hydra]

Tsurany schreef op zaterdag 1 mei 2021 @ 22:51:
Zorg er vooral voor dat je de REST standaarden juist gebruikt en een micro service architectuur aanhoud. Dan is een API vervangen echt plug en play.

Wat een bizar slecht advies.

Microservices zijn vooral een bedrijfsarchitectuur om te kunnen schalen naar veel teams die aan 1 architectuur werken. Voor een enkel persoon of een enkel team is het complete overkill die alleen maar veel complexiteit toevoegt. @peize9 negeer dit alsjeblieft.

[Hydra]

fietser1997 schreef op zondag 2 mei 2021 @ 16:00:
Daarnaast heb support spring t/m java 14

Spring ondersteunt Java 16 (vooral records dus) gewoon hoor.

[Hydra]

peize9 schreef op zondag 2 mei 2021 @ 16:48:
Zit er trouwens nog veel performance verschil tussen Java EE en PHP?

De kans dat je database de performance bottleneck gaat zijn is veel groter dan dat de taal dit is. Java is an sich relatief snel, maar de kans dat dat voor jou meer impact gaat hebben dan de database, of gewoon je eigen plezie,r is nihil

[Tsurany]

Hydra schreef op maandag 3 mei 2021 @ 13:27:
[...]


Wat een bizar slecht advies.

Microservices zijn vooral een bedrijfsarchitectuur om te kunnen schalen naar veel teams die aan 1 architectuur werken. Voor een enkel persoon of een enkel team is het complete overkill die alleen maar veel complexiteit toevoegt. @peize9 negeer dit alsjeblieft.

Juist als je niet weet wat je op lange termijn op wilt zetten is het een handig principe om toe te passen aangezien je flexibel blijft en niet een enorme code base opzet die je later niet eenvoudig kan herbouwen.

[Haan]

Tsurany schreef op maandag 3 mei 2021 @ 15:50:
[...]

Juist als je niet weet wat je op lange termijn op wilt zetten is het een handig principe om toe te passen aangezien je flexibel blijft en niet een enorme code base opzet die je later niet eenvoudig kan herbouwen.

Maar je zadelt jezelf wel op met alle extra complexiteit die er bij komt kijken. Microservices zijn niet eenvoudig. Zeker aangezien we het over een hobby project van - met alle respect - een niet al te ervaren developer lijken te hebben zou ik zeggen, simpel beginnen en hanteer vooral het YAGNI principe

[Hydra]

Tsurany schreef op maandag 3 mei 2021 @ 15:50:
Juist als je niet weet wat je op lange termijn op wilt zetten is het een handig principe om toe te passen aangezien je flexibel blijft en niet een enorme code base opzet die je later niet eenvoudig kan herbouwen.

Komop zeg. Je hebt geen enkele indicatie dat wat de TS gaat doen moet gaan schalen naar 4 of meer teams. Er is nul reden om dit nu al aan te nemen. Daarbij legde je deze nuance absoluut niet in je eerste reactie en was het gewoon een simpel "doe vooral microservices" wat nergens op slaat.

Ik ben op dit moment bezig met de start van een microservice architectuur die inderdaad moet gaan schalen binnen het bedrijf naar een team of 4 (of meer). Maar dit is puur omdat we weten dat de scope gewoon heel omvangrijk is. Dat is absoluut niet de situatie waar de TS in zit.

Het is overduidelijk een beginner en vooral voor een beginner is het gewoon een bizar slecht advies. En dat is wat mij betreft ook geen kwestie van meningen.

Je "dan is een API vervangen echt plug en play" doet me vermoeden dat je zelf nieteens ervaring hebt met microservices maar het vooral hebt van horen zeggen.

[ Voor 15% gewijzigd door Hydra op 03-05-2021 16:14 ]

[Tsurany]

Hydra schreef op maandag 3 mei 2021 @ 16:13:
Het is overduidelijk een beginner en vooral voor een beginner is het gewoon een bizar slecht advies. En dat is wat mij betreft ook geen kwestie van meningen.

Dan ga ik er niet verder op in.

[JustAnotherDev]

@peize9 beste tip die ik je kan meegeven is vooral, kies iets wat je snel hebt draaien en parkeer alle 'extras'. Als je een tutorial van 10 minuten vind om een REST api op te zetten, gebruik die en kijk er daarna niet naar om.

Tenzij je doel is om de perfectie API te maken icm met een bepaalde stack, wil je niet bij een hobby project stranden op het eerste component want nieteens het doel ansich is.

Als je zegt: "om zowel websites als computer software te verbinden met een database(mysql)", maak dan een REST API icm database. Maak een website die bijv minimaal CRUD (of bijv BREAD etc) voor een REST resource kan uitvoeren en daarnaast misschien bijv een Android applicatie die hetzelfde kan.

peize9 schreef op zondag 2 mei 2021 @ 16:59:
[...]

Nope, maar ik vind de keuze nog steeds moeilijk dus zit ik maar een beetje te zoeken naar andere redenen om specifiek iets te kiezen.

Voor beide varianten zou je in enkele uren met een goede tutorial een poc gemaakt moeten kunnen hebben. Dan kan je daarna op basis van je ervaring afwegen wat het best bij je past.

imho is je grootste gevaar om te verzanden in details waarbij je uiteindelijk maar 1% maakt van wat je initieel in gedachte had.

[ Voor 5% gewijzigd door JustAnotherDev op 03-05-2021 17:50 ]