<div dir="ltr">Hello,<div><div><br></div><div>in terms of the structure, here is a list of the most relevant/important modules/folders:</div><div><br></div><div>* admin-ui: Node.js application for our UI, bundled as a JAR file</div><div>* model: contains API and JPA implementation of the "data model"</div><div>* jaxrs: contains the REST endpoints of the server, some are used as "public API endpoints" (such as the sender or device registration), and others are less or more not public, they back the UI, and are protected by keycloak</div><div>* service: Contains a "service layer", basically less or more smart API wrappers around the DAOs, which are implemented via JPA</div><div>* push/model: Contains some push specific model classes, also reused by our java client</div><div>* push/sender: most important package. Here happens the most important: Sending of the push notifications, which is implemented via JMS, and the metrics processing (also via JMS), and storing metrics to the DB layer</div><div>* servers: builds the WAR files (for our custom keycloak, and our ag-push.war file)</div><div><br></div><div>Besides that we have docker-compose files, and database configuration (e.g. separated DB docker files)</div><div><br></div><div>Also, in the appendix of our users guide there is a bit of arch. overview:<br></div></div><div><a href="https://aerogear.org/docs/unifiedpush/ups_userguide/index/#appendix">https://aerogear.org/docs/unifiedpush/ups_userguide/index/#appendix</a><br></div><div><br></div><div>HTH,</div><div>Matthias</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 26, 2017 at 3:44 PM, Polina Koleva <span dir="ltr"><<a href="mailto:polina.n.koleva@gmail.com" target="_blank">polina.n.koleva@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
I am a masters student applying for GSOC project "HBase/Apache Kafka in<br>
UnifiedPush Server".<br>
I am exploring the codebase of the project so that I can understand the<br>
whole logical structure of it and its full functionality.<br>
I have noticed that it is divided into "modules". So I am thinking that<br>
maybe it will be good somewhere to have a brief description of each module<br>
and its function and maybe a diagram which module uses which. This can give<br>
a quick start of a developer new to the project and he can easily understand<br>
into which module to dive deeply. If you think it is a good idea, I can<br>
start doing it. Moreover, it will help me either.<br>
Besides, I have seen other open source projects organised in such a modular<br>
manner.<br>
Why have you decided to do it so modularly? And is this the practice<br>
usually?<br>
<br>
Sorry, if such documentation already exists and I haven't found it.<br>
<br>
Best regards,<br>
Polina Koleva<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://aerogear-dev.1069024.n5.nabble.com/Documentation-of-UnifiedPush-Server-s-modules-tp12921.html" rel="noreferrer" target="_blank">http://aerogear-dev.1069024.<wbr>n5.nabble.com/Documentation-<wbr>of-UnifiedPush-Server-s-<wbr>modules-tp12921.html</a><br>
Sent from the aerogear-dev mailing list archive at Nabble.com.<br>
______________________________<wbr>_________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div></div></div>
</div>