Prodej módní značky DANNYS clothing
Zobrazují se odpovědi 1 až 2 z 2

API Platform - použití jako microservice

  1. Ahoj,

    v návrhu API jsme se rozhodli rozdělit jednotlivé business celky do microservices. Pro větší část z nich jsme se rozhodli o implementaci v PHP, konkrétně Symfony. Nedávno jsem začal pracovat s API Platform a napadlo mě, že by se to možná dalo použít i zde, ale řeším několik problémů.

    1) Uživatelé budou dostupni pod 1 microservice, ke které musí všechny ostatní přistupovat. OAuth je řešen také samostatnou microservice. Neznáte jednoduchý způsob, jak toto implementovat v API Platform? Ideálně přímo knihovnu?
    2) API Platform generuje dokumentaci, což je super feature, ale určitě chceme mít 1 velkou dokumentaci. Jak byste řešili "merge"?
    3) Chceme implementovat i Graphql, ale už z principu nemůžeme mít na každé microservice vlastní instanci GraphQL. Napadlo mě řešení samostatnou microservice, která bude implementovat GraphQL nad REST endpointy. Máte někdo tip na řešení?

    Pokládám si především otázku, zda je API Platform vhodné řešení, zda by nebylo lepší pomocí Symfony Flex a pár knihoven udělat lightweight implementaci. Co myslíte?

    Mj. architekturu stojící na microservices jsme volili i z toho důvodu, že určité komponenty jsou psané v GoLang a Python. Proto není možné couvnout z tohoto požadavku.

  2. Co se právě děje na Webtrhu?
  3. Víc než na technologii podle mě záleží, jestli se vyplatí dělat něco nového víc než udělat to jednoduše v tom co umím. Kdybych se rozhodoval na základě toho co píšeš, tak bych volil lightweight implementaci.

    Většinou se spíš setkávám s tím, že když se zavádí nová technologie, tak to narazí na problémy, které předem nejsou vidět a pak je to svazující. Například u webdesignu (css, html, javascript) jsem zastánce psát to tak, jak by se to psalo před 5 lety. I když mi grafik/kodér vysvětluje jak je to super a i já sám to vidím jak je to super, ale skoro vždy když to povolím, tak nakonec nějak narazíme na problém a musí se to ohejbat. (Mluvim o technologii, nikoli o starem designu.)

    Stejně tak programování, vždy se mi osvědčila lightweight implementace. I když nové technologie a knihovny také zavádím, ale vyžaduje to hlubší analýzu a hlavně sepsat kuchařku pro všechny co s tím budou nějak pracovat, aby se předcházelo problémům (alespoň do doby, než se s tím naučí pracovat celý tým). A když mám pochybnost, tak mě nikdo nepřesvědčí a musím si to nastudovat a ověřit sám. Ale když už jsem přesvědčený, tak se klidně pustím do změny frameworku u aktivního projektu.

    Naučil jsem se věřit pocitu, že i když zatím nevím proč, tak to možná není dobrý nápad. Trochu tenhle pocit cítím z toho co píšeš.

Hostujeme u Server powered by TELE3