Moin,
in der Vergangenheit habe ich Webseiten im folgenden Stil aufgebaut:
Irgendein Script zieht sich ein Template und schmeißt die fertige HTML
Seite zum Browser. Wenn man was interaktiv nachgeladen werden soll wurde
ein Ajax Request abgeschickt.
Ich möchte gerade eine Software für kleine Unternehmen entwickeln und
habe überlegt, welche Architektur ich am Besten einsetzen kann um Front-
und Backend so gut wie möglich und sinnvoll voneinander zu trennen.
Meine Idee war folgende (vielleicht ist das auch der aktuelle
Standard??):
Irgendein Webserver, der nicht unbedingt der Hoster vom Backend ist
wirft eine HTML Datei mit Javascript raus.
Ein Backend, welches sich per REST ansprechen lässt, liefert reinen
Content wie z.B.:
{"Time" : "xxx", "Title" : "Das ist meine Website"}
und Javascript rendert den Content in das eigentliche Template.
So wäre man ja Platform und auch Technologie unabhängig, man könnte dann
auch Script gesteuert die API befeuern oder, oder, oder.
Wird das heute schon so gemacht? Welche Technologie sollte man für das
Frontend auswählen? Im Backend setze ich aktuell auf python3.
Viele Grüße,
Webhampel
> Javascript rendert den Content in das eigentliche Template Teeren und Federn! Oder Vierteilen. > wirft ... raus Wenn die Erde eine Scheibe wäre, könnte man dich auch an den Rand stellen und runterschubsen.
webhampel schrieb: > Wird das heute schon so gemacht? Welche Technologie sollte man für das > Frontend auswählen? Im Backend setze ich aktuell auf python3. das Backend ist austauschbar wenn Du REST benutzt. Python ist völlig okay! die aktuellen Platzhirsche im Frontend sind: Vue, Angular und React. Gibt ein paar Gegenüberstellungen im Netz, schau was Dir gefällt.
ThomasW schrieb: > webhampel schrieb: >> Wird das heute schon so gemacht? Welche Technologie sollte man für das >> Frontend auswählen? Im Backend setze ich aktuell auf python3. > > das Backend ist austauschbar wenn Du REST benutzt. Python ist völlig > okay! > > die aktuellen Platzhirsche im Frontend sind: Vue, Angular und React. > Gibt ein paar Gegenüberstellungen im Netz, schau was Dir gefällt. Super, danke dir. Ist die Architektur denn der aktuelle Stand der Technik oder würde man das anders aufbauen?
webhampel schrieb: > uper, danke dir. Ist die Architektur denn der aktuelle Stand der > Technik oder würde man das anders aufbauen? Ja, Vue, Angular und React sind im Moment aktueller Stand. Mir persönlich gefällt Vue am Besten (vuejs.org), das mag aber subjektiv sein. Backend kannst du gut mit python3 machen. Wenn du es auch in JavaScript schreiben möchtest, kannst du auch NodeJS nehmen.
ThomasW schrieb: > schau was Dir gefällt. Da sehe ich das Problem, der Wurm muss dem Fisch schmecken, nicht dem Angler. Ja ich weiss, die Realitaet sieht anders aus, das interessiert bei Webentwicklung fast niemanden (zumindest nicht die Entwickler und Entscheider). wendelsberg
Wenn man nicht basteln möchte, könnte man auch ASP.net nehmen.. Scnr
wendelsberg schrieb: > ThomasW schrieb: >> schau was Dir gefällt. > > Da sehe ich das Problem, der Wurm muss dem Fisch schmecken, nicht dem > Angler. Ja ich weiss, die Realitaet sieht anders aus, das interessiert > bei Webentwicklung fast niemanden (zumindest nicht die Entwickler und > Entscheider). > > wendelsberg Was genau kritisierst Du? Ernsthaft, ich verstehe nicht was Du da sagen willst - das ist komplett inhaltsloses rumnörgeln. Denn selbstverständlich macht es Sinn, sich für den Einstieg ein Framework zu suchen was zu einem passt und welches es in ein paar Jahren (vermutlich) noch geben wird.
Dunno.. schrieb: > Wenn man nicht basteln möchte, könnte man auch ASP.net nehmen und in welchem Browser läuft das so?
Sag erst mal was deine Software leisten soll, dann macht man sich Gedanken über die verwendete Architektur und wählt die Frameworks aus. "Ich verwende Python im Backend" - und warum, gibts dafür zwingenden Gründe?
Dunno.. schrieb: > Wenn man nicht basteln möchte, könnte man auch ASP.net nehmen.. Der größte Schrott im Netz und das dann mit "nicht basteln" anpreisen. Du hast Humor.
ThomasW schrieb: > ein Framework zu suchen was zu einem passt Da hat ja niemand was dagegen, aber die Formulierung war: ThomasW schrieb: >> ThomasW schrieb: >>> schau was Dir gefällt. Und da kommt eben in den letzten 5 Jahren oft nur noch fast unbenutzbares Bling heraus. Und ja, ich glaube, dass gerade dabei diejenigen, die nach "aktueller Technologie" fragen, besonders gefaehrdet sind, mehr auf Show als auf Benutzbarkeit zu achten. wendelsberg
wendelsberg schrieb: > Und da kommt eben in den letzten 5 Jahren oft nur noch fast > unbenutzbares Bling heraus. Und ja, ich glaube, dass gerade dabei > diejenigen, die nach "aktueller Technologie" fragen, besonders > gefaehrdet sind, mehr auf Show als auf Benutzbarkeit zu achten. jain ... es geht ja hier um die Technologie, nicht um Design. Deshalb bleib ich bei meiner Aussage: nehm das, wozu Du einen guten Zugang findest! mit der fehlenden Usability in vielen Projekten, da allerdings geb ich Dir Recht. Entweder viel zu sehr aus technischer Sicht oder zu Verspielt, zu selten wirklich aus Sicht der Leute die das Nutzen sollen. Als wollten manche alle Fehler wiederholen, die bereits auf dem Desktop gemacht wurden. Aber das ist eigentlich auch nicht der Job eines Entwicklers, dafür gibt es Designer. Die aber leider Geld kosten ...
Ich habe viel Erfahrung mit MVC oder MVVM Frameworks gemacht. Klingt theoretisch sinnvoll, ist aber in der Praxis scheiße. Hauptproblem ist, dass man MVC oder MVVM nur beherrscht, wenn jeder Entwickler quasi ein Full-Stack Entwickler ist oder man in den Abstraktionsebenen glasklare und unmissverständliche "Schnittstellen" definiert. Beides scheitert in der Praxis. Leider ist gerade im Webbereich vieles "heißer Scheiß", was eigentlich einfach nur furchtbar beschissen ist. Das Konzept Server und Frontend durch eine API, in welcher Form auch immer, scharf zu trennen finde ich persönlich sehr gut. Ein Freund von extensiven JS-Frameworks bin ich nicht. Ich habe dafür schon zu viele Implementationen gesehen, die nicht gut sind. Z.B. Eingabechecks nur im Frontend usw. Man braucht für die meisten modernen Webseiten kein JS oder nur einen sehr minimalen JS-Code. Nur wenn viel Multimedia dazu kommt, wird es sinnvoll JS üppig im Frontend einzusetzen. Die Art und Weise wie JS heutzutage im Frontend eingesetzt wird, ist absurd.
A. N. schrieb: > Man braucht für die meisten modernen Webseiten kein JS oder nur einen > sehr minimalen JS-Code. das ist völlig korrekt! Allerdings möchte der TE Webapplikationen entwickeln, da geht (derzeit) nicht viel ohne JavaScript.
ThomasW schrieb: > Webapplikationen Fragt sich, was man genau unter Webapplikation versteht. Heutzutage wird selbst eine simple Webseite als "Webapplikation" verkauft und manchmal tatsächlich als Webapplikation entwickelt. So von wegen mit Kanonen auf Spatzen schießen und sich einen Haufen Probleme einhandeln.
A. N. schrieb: > ThomasW schrieb: >> Webapplikationen > > Fragt sich, was man genau unter Webapplikation versteht. Heutzutage wird > selbst eine simple Webseite als "Webapplikation" verkauft und manchmal > tatsächlich als Webapplikation entwickelt. So von wegen mit Kanonen auf > Spatzen schießen und sich einen Haufen Probleme einhandeln. Ich spreche tatsächlich von einer Webapplikation, die auf mobilen Geräten, aber ebenso im Büro von den Büromitarbeitern genutzt werden soll. Im weitesten Sinne gehts um Auftragsmanagement für kleinere Firmen. Hier will ich die Software natürlich so generisch wie möglich bauen, damit ich die nicht nur beim Gärtner, sondern auch beim Tischler etc einsetzen kann. Wenn ich hier quasi Formulare individuell hinterlegen möchte, so möchte ich im Backend nur sagen wie viele Felder mit welchen Namen es geben soll und Javascript muss dem Nutzer das dann zusammenrendern. Das ganze muss für den Benutzer einfach ohne Reload der Website funktionieren, wenn er irgendwas ausgewählt hat, allein deswegen muss ich schon auf Javascript im Frontend setzen. Ich war mir halt nur nicht sicher, ob man das aktuell wirklich so strikt trennt, also Front und Backend. Ich habe jahrelang OTRS Module entwickelt und dort war alles eher etwas mehr verheiratet... Q vom MI6 schrieb: > Sag erst mal was deine Software leisten soll, dann macht man sich > Gedanken über die verwendete Architektur und wählt die Frameworks aus. > > "Ich verwende Python im Backend" - und warum, gibts dafür zwingenden > Gründe? Ich schreibe alles von Grund auf selber und kann mir aussuchen, was ich wo nehmen möchte und mit Python komm ich sehr gut klar. Ich könnte auch c#, perl oder c++ nehmen. Allerdings finde ich eine interpretierte Sprache da irgendwie besser, weil man nicht jedes Mal alles neu kompilieren muss und außerdem kommt man gerade mit Python super schnell ans Ziel. Außerdem möchte ich Servermäßig auf Linux setzen, weil ich mich da besser auskenne... Eigentlich nur deswegen. Dunno.. schrieb: > Wenn man nicht basteln möchte, könnte man auch ASP.net nehmen.. > > Scnr Ich habe hier tatsächlich noch ein Buch stehen "asp.net 2008" ... vor 12 Jahren war das tatsächlich nicht so gut, wie ich mir das gewünscht hätte und habe nur ein Projekt damit umgesetzt und dann das ganze verworfen. Mag sein, dass ich asp.net da heute unrecht tue, aber damals war das wirklich nicht so meins.
Ich weiss ja nicht was da für Python gibt aber wenn das was formularlastiges und eine typische Geschäftsanwendung mit umfangreichen Formularen werden soll würde ich mich nach einem komponentenbasierten Framework umschauen. Das fühlt sich dann so an als würde man eine Desktopanwendung bauen, Webservices definiert (WSDL per Tool) man nur noch und werden automatisch generiert bzw. merkt davon nix mehr, ja das funktioniert heute so wenn das Framework was taugt. In der Profiliga entwickelt man gegen ein Metaframework das hinten das entspr. Frontend ausspuckt: Web, (feature-abgespecktes) Mobilefrontend oder klassisches Desktopanwendung. Ich kenne ASP.NET nicht aber ich meine das hat zumindest ansatzweise ähnliche Fähigkeiten.
Ich verwende fuer das Backend, sprich Datenbank < - > Webseite, ausschliesslich php. Wenn man sich da etwas von Frameworks fernhaelt erhalt man langlebigen, stabilen Code. Dh das php macht seine Datenbnak interaktionen und stellt eine HTML seite zusammen. Auf der HTML Seite koennen auch Javascript Elemente sein.
Joggel E. schrieb: > Ich verwende fuer das Backend, sprich Datenbank < - > Webseite, > ausschliesslich php. Wenn man sich da etwas von Frameworks fernhaelt > erhalt man langlebigen, stabilen Code. > > Dh das php macht seine Datenbnak interaktionen und stellt eine HTML > seite zusammen. Auf der HTML Seite koennen auch Javascript Elemente > sein. So habe ich das in der Vergangenheit ebenfalls gemacht, aber das scheint mir nicht mehr zeitgemäß zu sein.
Ersetze PHP durch eine hippe, "moderne" Programmiersprache. Dann ist es wieder "modern". Ich mag PHP zwar nicht, weil es dem Entwickler zu viel Freiheit lässt Mist zu produzieren, aber es ist pragmatisch PHP zu nutzen, wenn man ohnehin PHP Nutzer ist. Kannst ja PHP nen modernen touch geben, indem du z.B. Hacklang nutzt, was so aus der PHP Ecke erwachsen ist.
Joggel E. schrieb: > Ich verwende fuer das Backend, sprich Datenbank < - > Webseite, > ausschliesslich php. Ich auch. Das funktioniert bei den meisten Hostern auch problemlos und man kann relativ schnell, eine gute, funktionierende Webseite bauen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.